Mac OS X Mavericksがフリーズし、メモリ不足になると応答を停止する

それは一日おきに起こり、症状は控えめに言っても奇妙です。コンピュータは依然としてある意味で応答します。マウスを動かすと、ヘッドフォンの音量ボタンが機能します。キーボードは何もしませんが、クリックもしません。ホバー状態は表示されません。マウスポインターが実際に動かされていないかのようです。

SSHを使用して別のコンピューターからログインするか、携帯電話からリモートを使用してログインすると、そのコンピューターを使用できます（Rowmoteを使用しています）。非常に低速ですが、応答します。

この状態でできることはほとんどありません。新しいアプリケーションの起動はルーレットです。たとえば、アクティビティモニターを起動することはできますが（奇妙なことは何もありません）、その後コンソールを起動することはできませんでした。アプリを閉じると、最終的にリモコンにも応答しなくなるまで奇妙な結果が出ました。興味深いことに、リモートアプリケーションは接続が失われたとは考えなかったので、リモートコマンドを受信して​​確認しました。

/var/log/system.log発生した瞬間からの関連する出力は次のとおりです。

Jan  3 10:39:19 knifen.local WindowServer[119]: CGXCreateShmem : mach_make_memory_entry(268453900: unknown error code) : Cannot map memory
Jan  3 10:39:19 knifen.local WindowServer[119]: _CGXCreateWindowInline: Creation failure 1007
Jan  3 10:39:19 knifen.local Dock[15204]: CGSNewWindowWithOpaqueShape: Cannot create window
Jan  3 10:39:19 knifen.local WindowServer[119]: CGXCreateShmem : mach_make_memory_entry(268453900: unknown error code) : Cannot map memory
Jan  3 10:39:19 knifen.local WindowServer[119]: _CGXCreateWindowInline: Creation failure 1007
Jan  3 10:39:19 knifen.local Dock[15204]: CGSNewWindowWithOpaqueShape: Cannot create window
Jan  3 10:39:28 knifen.local WindowServer[119]: BUG in libdispatch: 13A603 - 2930 - 0x1000480c
Jan  3 10:39:51 knifen kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Jan  3 10:40:50 knifen.local Spotify[13941]: Got disconnected: Error Domain=GCDAsyncSocketErrorDomain Code=4 "Read operation timed out" UserInfo=0xfa075f0 {NSLocalizedDescription=Read operation timed out}
Jan  3 10:40:55 knifen kernel[0]: IOHIDSystem: postEvent LLEventQueue overflow.
Jan  3 10:41:50 knifen.local hidd[95]: IOHIDEventQueue unable to get policy for event of type 11. (e00002e8)
Jan  3 10:41:56 --- last message repeated 113 times ---

私はここで何も不思議に思っていません。もしヒントがあればそれは良いと思います。Apple側のエンジニアリングは悪いようです。

OSのディスク容量が不足している場合、システムの重要な部分をオンラインで維持してクラッシュを制御し、変更が保存されているアプリがクリーンアップアクティビティまで存続できるようにするために、設計上問題が発生します開始します。

MavericksはRAMの全量を/ var / db / sleepimageに割り当てる可能性がはるかに低いため、OSが動作条件に応じてスリープイメージを拡張するための小さなスペースを必要とする場合、そのスペースを事前に割り当てることに慣れていた人々は驚かされる可能性があります。

主なヒントは、仮想メモリシステムに負荷がかかり、赤のメモリプレッシャーで実行されるワークロードがある場合、起動可能なボリュームに数ギガバイトの空き領域を保持することです。

これが私の推奨事項です：

• マーベリックスとヨセミテの「記憶圧」はどのスケールまたは基準に準拠していますか？コマンドの監視とメモリ不足の原因となる情報がいくつかあります
• システムを起動し、1人のユーザーでログインし、すべてのアプリケーションを終了します
• 活動モニターを開き、メモリ画面を観察/記録する
• マシンをスリープ状態にして、30秒後にスリープ解除する
• 実行sudo du -sm /var/vm/*して、スリープイメージファイルのサイズと、スワップファイルがディスク上に作成されているかどうかを確認します。

仮想メモリシステムを黄色の領域に配置してメモリの負荷を軽減するプログラムを実行する場合は、ディスク上に理想的な十分な空き容量を確保して、合計メモリフットプリントと一致させる必要があります。おそらくOSだけですべてのスペースが必要になるわけではありませんが、特に、リストのようにマッハメモリエラーが発生している場合、実行中のワークロードには、許可するよりも少し多くの空きスペースが必要です。

さらに、システムの調整が正しくないと感じた場合は、sysdiagnose上記のようにクリーンブート後に実行し、システムが目的のワークロードを適切に実行しているときにもう一度sydiagnoseメモリを実行すると、バグレポートを簡単に提出できます。システムの破壊を開始するための割り当て。Appleが選択できるより良い選択肢がある可能性もありますが、ソフトウェアにバグがあるか、メモリがリークしていて、有限のリソースが使い果たされたときにシステムが意図したとおりに壊れている可能性もあります。詳細がなければ、どちらが正しいのかを判断するのは困難です。

「shmem」は共有メモリであり、OS Xは共有メモリの割り当てに失敗しています。したがって、コンピューターのメモリが不足しているようです。RAMとハードドライブの両方のメモリです。これは事実ですか？フリーズ時には、約1GBの空き容量があるようです。

• ファイルを削除してディスク容量を解放する
• アプリケーションを閉じてメモリを解放する

この特定のケースでは、後でログに、Spotlightがマウントされたスパースバンドルボリュームのインデックスを作成しようとしたため、バッキングディスクの領域が不足したことが示されました。