4GB RAMラップトップを持っています。先週、私のシステムはかなりフリーズしていました。統計を確認したところ、2 GBまたはRAMおよび1 GBキャッシュが使用されています。負荷は約1.2程度です。そのため、18.04といくつかの通常のプログラムを再インストールしました。ただし、すべてが閉じている場合でも、使用されていないセッションは2 GBを示しますRAM消費はシステム負荷インジケータです。下のスクリーンショットを確認してください。
これが普通のことなのか、自分のハードウェアが心配なのか知りたい。ありがとう。
少し背景情報。この18.04の新規インストールの前に、AMPPSのインストールが不完全でした。また、Inkscape(私がPPAからインストールしたもの)は、過去2週間にときどきクラッシュしていました。
アップデート1:
$ swapon
NAME TYPE SIZE USED PRIO
/swapfile file 2G 2.5M -2
スワップサイズを増やす必要がありますか?
アップデート2:
GnomeクラシックDEを使用して何か効果がありますか?
しかし、すべてが閉じていても、ゼロユースセッションは2 GBを示しますRAM消費はシステム負荷インジケーターです。。。これが通常のものか、ハードウェアについて心配する必要があるかを知りたいです。ありがとう。
私のシステムにも同じメモリ使用量があるため、これは正常だと思います。私は現在何も実行しておらず、メモリ使用量は2.0 GB、キャッシュ1.8 GBですが、4 GBのスワップスペース(2 GBのスワップファイルと2 GBのzram)もあり、スワップピネスは10に設定されています。
私は zram を通常のスワップと一緒に、4GBのRAMで、〜2012の旧世代のi3プロセッサを搭載した東芝のラップトップのハードドライブの代わりにSSDを使用して、問題なく動作します。
私が持っているスワップスペースの量を知る方法は?
swapon
を使用して、スワップ領域の量を調べます。
増やすべきですか?はいの場合、それを行う方法は?
スワップファイルのサイズを増やすことはお勧めしませんが、zramを使用してスワップサイズ全体を増やすことをお勧めします。
Zramを使用すると、RAMサイズの1/2がスワップファイルに自動的に追加されます。スワップファイルのリターンが減少することはありません(HDDアクセスは、約10分の1遅くなりますRAMアクセス)。
Zramを使用してスワップ領域を増やすには、次のコマンドを実行します。
Sudo apt update
Sudo apt install zram-config
Sudo systemctl enable zram-config
Sudo systemctl start zram-config
Zramが使用されていることを確認するには、swapon
を実行するとzramがリストされます。
次に例を示します。
~$ swapon
NAME TYPE SIZE USED PRIO
/swapfile file 2G 101.9M -2
/dev/zram0 partition 486.1M 209.3M 5
/dev/zram1 partition 486.1M 210.1M 5
/dev/zram2 partition 486.1M 208.6M 5
/dev/zram3 partition 486.1M 206.8M 5
Ubuntu wikiでは、最小システム要件には4 GBのRAM Ubuntuデスクトップの場合が含まれます。これは、アプリケーションの実行を考慮せず、Ubuntuの場合のみです。
https://help.ubuntu.com/community/Installation/SystemRequirements
考えられるのは、Ubuntuのより軽量なバリアントを使用することです。同じWebページにはいくつかの提案があり、ページの下部にリストされています。または、可能であれば、コンピュータのRAMの量を増やすことを検討してください。
システムメモリの使用量とメモリ割り当ては、特定のハードウェアでシステムの使用可能なメモリに応じて調整されます。多くの変数に応じて、実際に使用されるメモリはシステムごとに異なる場合があります。一般に、システムのメモリが不足していない限り、メモリ使用量が予想より高くても心配する必要はありません。
Ubuntu 16.04から18.04で使用されているGnomeを実行している一部のデバイスには既知の問題があります。RAM Gnome 3のバグが原因です。これについて詳しくは、次のURLをご覧ください。 https:// gitlab.gnome.org/GNOME/gnome-Shell/issues/64
私たちが所有するワークステーションでは、19.04に更新してから、または19.10を実行するテストマシン以降、この問題は発生していません。