web-dev-qa-db-ja.com

Linuxは数秒ごとにフリーズします

Linuxボックスの1つ（Ubuntu 10.04 LTS、4倍のサイズのEC2で実行、68GBのRAMおよびそれぞれ3.25GHzの8つの仮想コア））が毎回フリーズするという問題が発生しています数秒。sshセッションで入力するとフリーズし、通常実行中のPostgresqlプロセスの1つでstraceを実行すると次のように表示されます。

02:37:41.567990 semop(7831581, {{3, -1, 0}}, 1

続行する前に数秒間（常にそのsemopでスタックします）。

OProfileは、ほとんどの時間がカーネル（60％）で費やされているのに対し、Postgresqlでは37％であることを示しています。

これらの停止（1日前に突然開始された）の結果、ボックスの負荷が0.7から10+になり、スタック全体の処理が遅くなります。

何が起こっているのかを追跡する方法について何かアイデアはありますか？ iostatは、ディスクが特に低速または過負荷であることを示していません。上部には、これらのバックアップが発生するたびに、ユーザーのCPU％が8％から約40％に急上昇していることが示されています。

linuxubuntuamazon-ec2postgresqlkernel
4
Zeppomedio

システムのセマフォが不足していると思われます。現在の設定については、ipcs -lを確認してください。これが postgresqlのセマフォの調整に関する情報 です。特に、システム全体のセマフォの最大数（SEMMNS）とセットあたりのセマフォの最大数（SEMMSL）を増やしてみます。 sysctl -pを使用して、これらの設定を変更できます。

2
Phil Hollenback

最終的に、PostgreSQLの設定「work_mem」まで追跡しました。これは、各Postgresプロセスがソートを実行するためのRAM）を設定します。（小さな）デフォルトをこぼしてしまいました。システムがディスクにヒットしました。これはEC2での死のキスです（そして、ディスクアクティビティの突然のスパイクは、iowaitの急速なバーストでカーネルをフリーズさせていました）。

1
Zeppomedio

この質問を見てください 256GBのメモリ/ 48コアのLinux-マシンは大量のメモリが残っているとスラッシング/窒息を開始します そしてmysqlとスワップの狂気に関するリンクが大容量のメモリで役立つかどうかを確認してください。

1
coredump

カーネルで費やされた時間のほとんどをすでに見つけているので、CONFIG_LATENCYTOPを有効にして、latencytopを実行して詳細を確認することをお勧めします。 oprofileでも実行できますが、latencytopの方がはるかに便利です。

1
al.

これが発生しているときに利用可能なエントロピーを確認してください。

cat/proc/sys/kernel/random/entropy_avail

Ubuntuには、必要のないときにシステムに実際の乱数を要求するという悪い習慣があるようです。これにより、このような状況が発生する可能性があります。ハードウェア乱数ジェネレーターを動作させてみてください。問題があれば、問題は解決します。

0
Kyle__

「68GBのRAM」を考慮すると、VMの非効率性に関連していると思われます。Postgresqlを再起動または再起動してみましたか？

0
poige

初めて96Gbメモリを搭載したサーバーにOracleサーバーをデプロイしたときに、同様の問題（一時停止が数分間隔であったという点で異なります）に遭遇しました。最終的に、ページアウトされる可能性のあるメモリの特定を担当するカーネルプロセスまで追跡しました。より小さなチャンクをチェックするようにプロセスを設定すると、より頻繁に問題が解決されました。

0
Greeblesnort