 | Решение проблем, связанных с использованием ресурсов
В этом разделе описывается материал по теме 306.2 экзамена на профессионала Linux высокого уровня (LPIC-3) 301. Эта тема обладает весом 4.
Из этого раздела вы узнаете, как:
- Определять наиболее вероятные источники проблем в зависимости от симптомов
- Определять узкие места в работе системы
В предыдущем разделе было рассказано, как можно посмотреть различные счетчики производительности в Linux-системе. Теперь настало время применить рассмотренные команды для решения проблем, связанных с использованием ресурсов, возникающих в вашей системе.
Методология диагностирования неисправностей
Прежде чем приступать к рассмотрению ограничений на количество ресурсов и детальному изучению работы вашей системы, спланируйте стратегию решения проблемы. Большинство стратегий сводятся к четырем шагам:
- Выявление симптомов.
- Определение первопричины неисправности.
- Внесение исправлений.
- Оценка результатов.
Выявление симптомов
Первым шагом в решении проблемы является выявление симптомов. Примером такого симптома может быть ситуация типа «электронная почта работает слишком медленно» или «у меня закончилось место на диске». Симптомы приводят к жалобам пользователей, которые не будут довольны до тех пор, пока эти симптомы не прекратятся. Однако не путайте симптомы с проблемой: очень часто проблема заключается совсем не в том, о чем сообщают ваши пользователи, хотя она и является причиной возникновения симптомов.
После того как вы выявили все симптомы, попытайтесь подсчитать количество случаев возникновения неполадок и выяснить условия, при которых это происходит. Слишком медленная работа системы электронной почты может заключаться в том, что получение электронных писем после их отправки, занимавшее секунды, теперь занимает несколько часов. А пользователь, у которого закончилось место на диске, должен был при этом выполнять какие-то действия, например, сохранять файл или выполнять пакетное задание.
Заключительный шаг - количественная оценка неполадок - преследует две цели. Первая – это позволить вам воспроизвести проблему, что позже поможет вам определить, решена ли проблема или нет. Вторая цель – получить больше подробностей о действиях пользователя, что поможет вам определить первопричину. Например, после того, как вы узнали, что задача, которая раньше выполнялась 5 минут, теперь выполняется час, вы можете осведомиться о характере этой задачи. В результате может выясниться, что задача получает информацию из базы данных, расположенной на другом сервере, который необходимо будет включить в сферу поиска первопричины неисправности.
Определение первопричины неисправности
Определение первопричины включает в себя использование команд, изученных в разделе Измерение степени загрузки ресурсов, позволяющих найти источник проблемы. Для этого вы должны исследовать ресурсы, такие как центральный процессор, память, диск и сеть. В идеальном случае вы сможете собирать данные непосредственно в момент наступления проблемы с помощью инструментов реального времени, таких как vmstat,
iostat и top. Если это невозможно, вам может помочь какая-нибудь утилита, собирающая статистику за прошедшие периоды, например утилита sar.
Если проблема связана с ресурсами, то возможны два варианта: либо один или более ресурсов системы будет загружен на 100%, и в этом случае причина должна быть очевидна, либо вы не обнаружите никакой явной перегрузки.
В последнем случае вы должны обратиться к базовому уровню. Базовый уровень – это набор эталонных данных, который вы можете использовать для сравнения наблюдаемых значений с "нормальными" значениями. Базовым уровнем для вашей системы может являться набор диаграмм или заархивированные отчеты утилиты sar, которые были созданы в период нормальной работы системы. Базовый уровень пригодится и позже, когда вы будете изучать прогнозирование потребностей в системных ресурсах.
По мере использования административных инструментов у вас начнет вырисовываться картина перовопричины неисправности. Может оказаться, что на вашем почтовом сервере застряло сообщение, заблокировав обработку остальных сообщений. А возможно, какое-либо пакетное задание полностью загружает центральный процессор.
На этом этапе необходимо точно убедиться, что вы правильно определили первопричину возникшей проблемы. Приложение, генерирующее огромный файл журнала событий, могло привести к тому, что на диске закончилось свободное место. Если вы неправильно решите, что первопричиной оказался файл журнала событий, и решите удалить его, диск снова может оказаться заполнен спустя некоторое время.
Внесение исправлений
Часто имеется несколько путей решения проблемы. Возьмем, например, пакетное задание, потребляющее все ресурсы центрального процессора. Если вы удалите задачу с помощью команды kill, пользователь, запустивший ее, вероятно, потеряет все свои данные, хотя остальные пользователи и получат в свое распоряжение ресурсы сервера. Вместо этого можно понизить приоритет процесса, чтобы высвободить часть ресурсов процессора для других задач. Как правило, выбор решения делается на ваше собственное усмотрение в зависимости от потребностей бизнеса и важности ситуации.
Оценка результатов
После того как вы предприняли действия по исправлению ситуации, необходимо вернуться и проверить, решена ли проблема. Доставляются ли электронные письма незамедлительно? Могут ли пользователи войти в систему? Если нет, нужно вернуться на шаг назад и посмотреть на первопричину снова – возможно, вы найдете дополнительный способ решения проблемы, который можно использовать. Если ваши действия не решили проблему, также необходимо убедиться, что в результате ситуация не усугубилась!
После того как проблема решена, определите, нужно ли предпринимать какие-либо дополнительные долгосрочные меры. Возможно, стоит ли рассмотреть возможность установки диска большего объема или переноса пакетного задания пользователя на другую машину. Если на машине выполняются неопознанные процессы, стоит выполнить более тщательную проверку безопасности сервера с целью убедиться, что он не используется злоумышленником.
Более сложные проблемы
Некоторые проблемы производительности очевидны. Пользователь жалуется на то, что что-то работает медленно, вы запускаете команду top, видите ненужный процесс, который загружает процессор, завершаете его выполнение, и система приходит в нормальное состояние. Ваш босс хвалит вас за хорошую работу, повышает вам зарплату и отпускает вас в этот день домой пораньше (ну, может быть, последняя часть выдумана).
Но что если проблема не столь очевидна? Иногда проблемы обусловлены не единственным фактором, а симптом может быть вызван чем-то таким, что на первый взгляд может показаться не относящимся к делу.
Swap-спираль
Память работает быстро, и, как правило, в системе установлено достаточное ее количество. Тем не менее иногда приложению требуется больше памяти, чем имеется в системе, или же несколько процессов сообща расходуют всю имеющуюся память. В таких случаях используется виртуальная память. Ядро выделяет область на диске и выгружает в нее страницы резидентной памяти так, чтобы активные приложения могли использовать ее. Когда выгруженная на диск память требуется приложению, она загружается обратно в ОЗУ; при этом из ОЗУ на диск могут выгружаться другие страницы памяти, чтобы освободить место для загружаемых данных.
Проблема этого механизма заключается в том, что скорость диска очень мала. Если вы обращаетесь к виртуальной памяти кратковременно, вы можете не заметить этого. Однако когда система начинает активно выгружать память на диск с целью освободить ОЗУ под нужды других задач, у вас появляются проблемы. Вы обнаруживаете, что количество дисковых операций ввода/вывода стремительно увеличивается, и кажется, что система не реагирует на ваши запросы. На самом деле, система не отвечает потому, что ваши приложения ожидают, пока их память будет перемещена с диска в ОЗУ.
Администраторы UNIX называют эту ситуацию swap-спиралью (или иногда более мрачно – смертельной swap-спиралью). В итоге система застопоривается, так как диски работают на пределе, пытаясь выгружать память из ОЗУ на диск и обратно. Если устройство для подкачки расположено на том же физическом диски, что и данные, дела обстоят еще хуже. После того как ваше приложение обращается к центральному процессору и отправляет запрос ввода/вывода, ему приходится ожидать завершения обработки подкачки еще дольше.
Явным признаком swap-спирали является абсурдно долгое время отклика системы на любое действие, даже на выполнение простейшей команды uptime. Кроме того, вы также увидите высокое значение средней загрузки, поскольку множество процессов находятся в очереди на выполнение вследствие затора в работе системы. Чтобы отличить эту проблему от проблемы, связанной с высокой загруженностью центрального процессора, вы можете запустить команду top и посмотреть, насколько сильно загружен процессор, или запустить команду vmstat и посмотреть, насколько активно используется подкачка. Как правило, решение заключается в том, чтобы поочередно завершать процессы до тех пор, пока система не придет в нормальное состояние; иногда в зависимости от характера проблемы ее можно просто переждать.
Нехватка места на диске
От приложений не требуется выполнения проверки на предмет возникающих ошибок.Многие приложения созданы в предположении, что все обращения к диску выполняются быстро и точно. Переполнение дискового раздела часто приводит к тому, что приложения начинают работать непредсказуемым образом. Например, приложение может занять все доступные ресурсы центрального процессора, пытаясь выполнить операцию снова и снова, не осознавая при этом, что продолжение работы невозможно. Чтобы посмотреть, что делает приложение в данный момент (если оно использует системные вызовы), можно воспользоваться командой strace.
В других случаях приложения просто перестают работать. Если Web-приложение не может получить доступ к базе данных, оно может возвращать пустые страницы.
Самый быстрый способ проверить, не заключается ли проблема в нехватке дискового пространства – это войти в систему и проверить доступное место с помощью команды du.
Заблокированные операции ввода/вывода
Когда процесс посылает запрос на выполнение какой-либо операцие ввода/вывода, ядро переводит процесс в состояние сна (sleep) до тех пор, пока запрос ввода/вывода не будет возвращен. Если с диском происходит что-то неординарное (например, вследствие возникновения swap-спирали, сбоя в работе диска или сетевого сбоя в сетевых файловых системах), в режим сна одновременно переводится множество приложений.
В состоянии сна процесс может быть прерываемым (interruptible) или неинтерпретируемым (uninterpretable). В первом случае можно завершить работу процесса, послав сигнал на завершение его работы, во втором случае это сделать невозможно. Состояние можно посмотреть с помощью команды ps aux. В листинге 12 показаны два процесса, один из которых находится в состоянии прерываемого сна, а другой – в состоянии неинтерпретируемого сна.
Листинг 12. Два процесса в состоянии сна
apache 26575 0.2 19.6 132572 50104 ? S Feb13 3:43 /usr/sbin/httpd
root 8381 57.8 0.2 3844 532 pts/1 D 20:46 0:37 dd
|
Первый процесс в листинге 12, httpd, находится в состоянии прерываемого сна, о чем говорит буква S после знака вопроса. Второй процесс, dd, находится в состоянии неинтерпретируемого сна. Состояния неинтерпретируемого сна чаще всего связаны с доступом к жесткому диску, тогда как состояния прерываемого сна относятся к относительно длительным операциям, например операциям NFS и сокетов.
Если вы обнаружили высокую среднюю загрузку (означающую, что в очереди на выполнение находится множество процессов) и множество процессов в состоянии неинтерпретируемого сна, возможно, проблема связана с вводом/выводом жесткого диска, - в результате либо сбоя в работе устройства, либо слишком большого количества одновременных операций записи/чтения на диск.
| |
