Как изолировать причины зависания системы в Unix / OSX - PullRequest
6 голосов
/ 16 марта 2009

Я нахожусь на OSX, и моя система перестает отвечать на запросы в течение нескольких секунд примерно каждые 10 минут. (Это дает мне вращающийся пляжный мяч смерти). Мне было интересно, есть ли какой-нибудь способ, которым я мог бы изолировать проблему (у меня много оперативной памяти, и нет постраничных / перегрузок) Какие-нибудь инструменты Unix / OSX, которые могли бы помочь мне контролировать и изолировать причину такого поведения?

Ответы [ 8 ]

4 голосов
/ 16 марта 2009

Activity Monitor (cmd+space, тип activity monitor), должен дать вам интуитивно понятный обзор того, что происходит в вашей системе. Если, как вы говорите, процессоры не засоряются, пожалуйста, обратите внимание на активность диска / ввода-вывода. Возможно, ваш диск движется на юг.

3 голосов
/ 25 марта 2011

В течение многих лет у меня постоянно возникали проблемы с зависанием системы. Кажется, что в целом они являются результатом ошибок файловой системы, однако Apple не делает достаточно для решения этой проблемы. Надежность системы должна быть в центре внимания на 100%, и я, безусловно, устал от этих проблем. Я начал перемещать множество файлов и всех резервных копий на том ZFS на сервере FreeBSD, и это немного помогает, поскольку он начал облегчать мой разум и позволяет быстрее восстанавливаться после проблем. Кроме того, я поместил системный том на большой твердотельный накопитель (240 ГБ, так как у меня много вспомогательных файлов, и я стараюсь не допустить слишком большого разделения символических ссылок) и папки «Пользователи» на другом диске. Это также помогло повысить надежность.

Сказав это, вы должны попытаться изучить spindump и stackshot, чтобы увидеть, сможете ли вы отловить замороженные процессы до того, как система полностью зависнет. Вполне вероятно, что у вас есть приложение или два, которые пытаются получить доступ к плохим блокам, и оно просто зависает в системе, или у вас есть процесс, блокирующий все остальные по какой-то причине с помощью системного вызова, который останавливает io.

За последние пару лет Apple несколько раз использовала мне стэкшот, чтобы выследить некоторых злобных педерастов, и следующая ссылка может пролить свет на то, как, возможно, лучше выследить этого гоблина: http://www.stormacq.com/?p=346

Также попробуйте: top -l2 -S > top_output.txt и проверьте результаты для процессов зависания / зомби.

Чем глубже вы углубитесь в это, вам может быть полезно подписаться на список разработчиков ядра (darwin-kernel@lists.apple.com), так как здесь есть очень и очень острые куки, которые могут пролить свет на некоторые из самых неясных вопросов и помогают точно понять, о чем говорят паники.

Кроме того, вы можете удалить все установленные виртуальные машины. Есть один разработчик, который, как я слышал из очень надежных источников, имеет очень дефектные проблемы с гипервизором, и было бы разумно разобраться с этим, если у вас есть какой-либо установленный. Возможно, пришло время очистить ваши кексы.

Но, в целом, нам действительно крайне необходимы лучшая файловая система и упреждающие механизмы для наблюдения за плохими блоками. Я похвалил этот день и кричал от радости, когда думал, что мы получим ZFS официально. Я сомневаюсь, что Lion намного лучше на фронте HFS +, и я, конечно, рассматриваю ZFS для моего тома Users + другое хранилище на рабочей станции из-за его способности вычищать плохие блоки и устранять подобные проблемы.

Они - основа нашего существования на оборудовании Apple, и, проработав в этой области в течение 20 лет и тысяч клиентов, сбой жесткого диска следует считать непростительным делом. Даже если настоящие mfgs не могут и не смогут это исправить, разработчики ОС должны лучше обрабатывать исключения и защищаться от таких сбоев, чтобы предотвратить потерю данных и ночные кошмары, подобные этим.

2 голосов
/ 16 марта 2009

Activity Monitor - это вершина GUI, и с Leopard вы можете использовать функцию «Образец процесса», чтобы посмотреть, на что ваши преступные задачи тратят большую часть своего времени. Также в Utilities вы найдете консоль, также известную как tail -f /var/log/messages.

2 голосов
/ 16 марта 2009

Я бы запустил смесь 'top' и tail -f / var / log / messages (или там, где находится ваш основной файл журнала).

Скорее всего, до / после зависания появится сообщение об ошибке. Оттуда вы можете начать отсеивать свои проблемы.

1 голос
/ 21 марта 2009

Используйте инструменты Apple. Честно говоря, это очень помогло в поиске таких зависаний.

1 голос
/ 18 марта 2009

Периодическая безответственность часто имеет место, когда происходит обмен. Достаточно ли у вас памяти в вашей системе? Изучите диск на предмет наличия пиков.

EDIT:

В последнее время на моем Mac наблюдалось похожее поведение, которое было вызвано повреждением файловой системы, поэтому OS X пыталась получить доступ к несуществующим блокам на диске и даже пыталась восстановить их с помощью Disk Manger, попросив меня переформатировать и переустановить. Выполнение этого и восстановление с помощью Time Machine помогли!

Если вы сделаете это, то дважды проверьте, что Журналирование включено на HFS на жестком диске. Это немного помогает избежать повторения.

1 голос
/ 16 марта 2009

Если другие ответы вас никуда не приведут, я бы запустил , проследил за временем безотказной работы и вел бы записи о времени и времени безотказной работы, когда оно зависало. Блокировка около каждые 10 минут очень отличается от блокировки точно каждые 10 минут; последний предлагает искать в crontab -l задания, начинающиеся с * / 10.

1 голос
/ 16 марта 2009

В качестве первой линии атаки я бы рекомендовал top работать в окне терминала, где вы можете его видеть, и наблюдать за тамошними заданиями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...