Mac OS X Mavericks se bloque, cesse de répondre en cas de manque de mémoire

Cela arrive tous les deux jours et les symptômes sont pour le moins étranges. L'ordinateur répond toujours dans un certain sens; Je peux déplacer la souris, les boutons de volume de mon casque fonctionnent. Leur clavier ne fait rien , pas plus que le fait de cliquer. Aucun état de vol stationnaire n'est présenté. C'est comme si le pointeur de la souris n'était pas vraiment déplacé.

Je peux utiliser l'ordinateur si je me connecte à partir d'un autre ordinateur en utilisant SSH ou en utilisant une télécommande de mon téléphone (j'utilise Rowmote.) C'est très lent, cependant - mais il répond.

Dans cet état, je peux faire très peu de choses. Démarrer de nouvelles applications est une roulette, par exemple, je pouvais démarrer Activity Monitor (rien d'étrange à voir) mais démarrer Console après cela n'était pas possible. La fermeture des applications a donné des résultats étranges jusqu'à ce qu'elle cesse enfin de répondre à la télécommande. Fait intéressant, l'application distante ne pensait pas qu'elle avait perdu la connexion, donc elle a quand même reçu et reconnu les commandes distantes.

Voici la /var/log/system.logsortie pertinente du moment où cela s'est produit:

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 ---

Je ne me demande vraiment rien ici, si vous avez des conseils, je pense que ce serait bien. Cela semble être une mauvaise ingénierie de la part d'Apple.

Lorsque le système d'exploitation manque de place sur le disque, de mauvaises choses se produisent par conception dans le but d'essayer de garder les parties critiques du système en ligne assez longtemps pour permettre un crash contrôlé et potentiellement laisser des applications avec des modifications à sauver survivre jusqu'à l'activité de nettoyage départs.

Mavericks est beaucoup moins susceptible d'allouer la totalité de la RAM à / var / db / sleepimage, de sorte que les personnes habituées à avoir cet espace préalloué peuvent rencontrer des surprises lorsque le système d'exploitation a besoin d'un peu de place pour développer l'image de veille si les conditions de fonctionnement l'exigent.

L'astuce principale serait de conserver plusieurs gigaoctets d'espace libre sur le volume de démarrage lorsque vous avez une charge de travail qui sollicite le système de mémoire virtuelle et s'exécute avec une pression de mémoire dans le rouge.

Voici mes recommandations:

• À quelle échelle ou mesure la «pression de mémoire» de Mavericks et de Yosemite adhère-t-elle? a de bonnes informations sur la surveillance et la pression de la mémoire sur commande
• démarrez votre système, connectez-vous un utilisateur, quittez toutes les applications
• ouvrir le moniteur d'activité et observer / enregistrer l'écran de la mémoire
• mettre la machine en veille et la réveiller 30 secondes plus tard
• exécutez sudo du -sm /var/vm/*et notez la taille de votre fichier image de veille ainsi que si des fichiers d'échange ont été créés sur le disque.

Vous voudrez avoir idéalement suffisamment d'espace sur le disque libre pour correspondre à votre empreinte mémoire totale si vous avez l'intention d'exécuter des programmes qui prennent le système de mémoire virtuelle en territoire jaune pour la pression de la mémoire. Vous n'aurez probablement pas besoin de tout cet espace uniquement pour le système d'exploitation, mais surtout si vous obtenez des erreurs de mémoire mach comme celles que vous répertoriez, la charge de travail que vous exécutez a besoin d'un peu plus d'espace libre pour croître que ce que vous autorisez.

De plus, si vous pensez que le réglage du système est incorrect, vous pouvez facilement déposer un rapport de bogue en exécutant sysdiagnoseaprès un démarrage propre comme décrit ci-dessus, une fois de plus lorsque le système exécute correctement la charge de travail prévue et une dernière sydiagnoseexécution une fois que vous avez causé la mémoire allocations pour commencer à briser le système. Il est possible qu'Apple ait pu faire de meilleurs choix, mais il se peut aussi que votre logiciel soit bogué / fuit en mémoire et que le système se brise comme prévu lorsque les ressources limitées qu'il a épuisées. Sans plus de détails, il est difficile de dire quel est le cas.

"shmem" est une mémoire partagée et OS X ne parvient pas à allouer de la mémoire partagée. Il semble donc que l'ordinateur manque de mémoire, à la fois la mémoire RAM et la mémoire du disque dur. Est-ce le cas? Au moment du gel, il semblait qu'il restait environ 1 Go d'espace.

• Libérez de l'espace disque en supprimant des fichiers
• Libérez de la mémoire en fermant les applications

Dans ce cas particulier, les journaux ont par la suite indiqué que Spotlight avait tenté d'indexer un volume de montage séparé, entraînant un manque d'espace sur le disque de sauvegarde.