53478


**Linux で、メモリーが明らかに不足していると判断する基準や方法はありますか？**  
・当初は、どこかの数値がマイナスになるのかと思っていたのですが、私が調べた限りではそんな単純な話ではないことが分かりました  
・あるサイトで「メモリのfreeが10%を切ったら」と書いてあったのですが、そういう判断基準がもしあれば教えてください

* * *

下記例の場合、「63/992＊100＝6.35」なので10%を切っている、という認識で合っていますか？

[code]

    $ free -wh
    　　　　　total        used        free      shared     buffers       cache   available
    Mem:      992M        790M         63M        7.5M          0B        138M         46M
    Swap:     4.0G        3.6G        446M
    
[/code]

* * *

また下記で何か気が付いた点があれば、アドバイスをお願いします

[code]

    $ top
    top - 20:52:00 up 77 days,  4:05,  1 user,  load average: 1.20, 1.24, 1.32
    Tasks: 314 total,   2 running, 312 sleeping,   0 stopped,   0 zombie
    %Cpu(s): 50.1 us,  0.2 sy,  0.0 ni, 49.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem :  1016772 total,    68156 free,   817020 used,   131596 buff/cache
    KiB Swap:  4194300 total,   426228 free,  3768072 used.    45568 avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                       
     1461 mysql     20   0 2278332 144568   4316 S  99.7 14.2  61489:41 mysqld                                        
      608 nginx     20   0  219260   1124   1076 S   0.3  0.1   3:17.01 uwsgi                                         
    19183 root      20   0       0      0      0 S   0.3  0.0   0:00.17 kworker/1:2                                   
        1 root      20   0   43360   1984   1312 S   0.0  0.2  13:56.35 systemd      
    
[/code]

**環境**  
・CentOS7


CC BY-SA 4.0
2019-03-16T13:20:30.467
53476
2019-03-17T02:35:12.150
2019-03-16T16:45:46.663
3060
7886
question
centos
Linux のメモリー不足判断基準について


「10%」も大まかな目安でしかなく、搭載しているメモリ量によって余裕の度合いは異なってきますよね？  
(1GBに対する残り100MBならカツカツだし、16GBに対する残り1.6GBならまだ踏ん張れそう)

実メモリが1GBしか無くてスワップの4GBもほぼ使い尽くしてる状況を見ると、明らかにメモリが足りていないと考えられます。VPSか何かでしょうか？

スワップ領域は大抵物理ディスクですから、メモリに比べて圧倒的にアクセス速度が遅いです。頻繁にスワップが発生しているならメモリの追加も検討すべきでしょう。

* * *

`top`コマンドの起動直後は「CPU使用率順」ですが、私がよく利用するのは`Shift`+`M` (大文字M)で「メモリ使用率順」に並べ替えます。

質問文の結果を見るとmysqldがリソースを食っていそうなので(起動時間も非常に長い)、可能であればサービスを再起動してみて、それでも改善しなければ詳しく調べを進めてみる…という段取りになりそうです。

**追記**  
スワップのサイズも「増やせば増やすほどいい」ものではなく、実メモリに合わせた推奨値があります。システムのRAM(実メモリ)が2GB以下なら、「スワップはRAMの2倍」程度が推奨値とされています。

参考:  
[システムの推奨 swap 領域 - Red Hat Customer
Portal](https://access.redhat.com/documentation/ja-
jp/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace)


CC BY-SA 4.0
2019-03-16T13:55:15.147
53478
2019-03-16T14:16:41.763
2019-03-16T14:16:41.763
3060
3060
53476
answer


swap の free が 50% を切ったら、 swap を増設すべきです。 swap は要は filesystem
なので、これの追加にはそこまでコストはかからないです。

十分に swap を積んだとしても、同時に利用されるメモリが足りていない場合、スラッシングが発生します。

これは `vmstat 1` などで、 bi と bo が常に動き続けていている場合、ほぼ確実に cpu のメモリが足りていません。


CC BY-SA 4.0
2019-03-16T13:59:52.140
53479
2019-03-16T13:59:52.140
754
53476
answer


CentOS7であれば、`free`コマンドの「`Mem`」行の「`free`」欄よりも、「`available`」欄を確認した方が、利用可能なメモリ量を把握するのに適していると思います。(`buffers`と`cache`は利用可能と考えてよい)(参考:
[【RHEL】linuxメモリのfreeとmeminfoの関係を図解し利用率の計算方法を説明してみる](http://nopipi.hatenablog.com/entry/2015/09/13/181026))

「明らかに不足している」は要件によりますが、OOM Killerが動作する状態は明らかにメモリ不足と考えてよいと思います。  
OOM
Killerが動作していないのであれば、スワップイン(`bi`)が常に発生しており、プロセス(この場合だと`mysqld`)のレスポンスが想定より悪ければ「不足している」と考えてよいと思います。


CC BY-SA 4.0
2019-03-17T02:35:12.150
53489
2019-03-17T02:35:12.150
20098
53476
answer