Debian медленно делает первые шаги по устранению неполадок

Обновлено: 21.11.2024

У всех рано или поздно возникают проблемы с веб-сервером или сайтом. Зная, где искать, когда вы сталкиваетесь с проблемой и какие компоненты являются вероятными виновниками, вы сможете быстро устранить эти проблемы и с меньшими трудностями.

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

Какие типы проблем типичны?

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

Мы рассмотрим их более подробно в следующих разделах, а пока вот простой контрольный список пунктов, на которые стоит обратить внимание:

Установлен ли ваш веб-сервер?
Работает ли веб-сервер?
Правилен ли синтаксис файлов конфигурации вашего веб-сервера?
Открыты ли настроенные вами порты (не заблокированы ли они брандмауэром)?
Ваши настройки DNS направляют вас в нужное место?
Указывает ли корень документа на расположение ваших файлов?
Отправляет ли ваш веб-сервер правильные индексные файлы?
Правильно ли указаны разрешения и права собственности на структуры файлов и каталогов?
Ограничиваете ли вы доступ через файлы конфигурации?
Если у вас есть серверная часть базы данных, работает ли она?
Может ли ваш сайт успешно подключиться к базе данных?
Настроен ли ваш веб-сервер для передачи динамического содержимого обработчику сценариев?

Это некоторые из распространенных проблем, с которыми сталкиваются администраторы, когда сайт работает неправильно. Точную проблему обычно можно сузить, взглянув на файлы журналов различных компонентов и обратившись к страницам ошибок, отображаемым в вашем браузере.

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

Проверьте журналы

Прежде чем слепо пытаться отследить проблему, попробуйте проверить журналы своего веб-сервера и любых связанных с ним компонентов. Обычно они находятся в /var/log в подкаталоге, относящемся к службе.

Например, если у вас есть сервер Apache, работающий на сервере Ubuntu, по умолчанию журналы будут храниться в /var/log/apache2 . Проверьте файлы в этом каталоге, чтобы узнать, какие сообщения об ошибках генерируются. Если у вас есть серверная часть базы данных, которая доставляет вам проблемы, она, вероятно, также будет хранить свои журналы в /var/log.

Еще нужно проверить, оставляют ли сами процессы сообщения об ошибках при запуске служб. Если вы попытаетесь посетить веб-страницу и получите сообщение об ошибке, страница с ошибкой также может содержать подсказки (хотя и не такие конкретные, как строки в файлах журнала).

Используйте поисковую систему, чтобы попытаться найти релевантную информацию, которая может указать вам правильное направление. Приведенные ниже шаги могут помочь вам в устранении неполадок.

Установлен ли ваш веб-сервер?

Первое, что вам нужно для правильного обслуживания ваших веб-сайтов, — это веб-сервер.

Большинство людей установили сервер до того, как дошли до этого момента, но бывают ситуации, когда вы могли случайно удалить сервер при выполнении других операций с пакетами.

Если вы работаете в системе Ubuntu или Debian и хотите установить веб-сервер Apache, введите:

В этих системах процесс Apache называется apache2.

Если вы используете Ubuntu или Debian и вам нужен веб-сервер Nginx, вместо этого вы можете ввести:

В этих системах процесс Nginx называется nginx.

Если вы используете CentOS или Fedora и хотите использовать веб-сервер Apache, введите это. Вы можете удалить «sudo», если вы вошли в систему как пользователь root:

Если вы используете CentOS или Fedora и хотите использовать Nginx, введите это. Опять же, удалите «sudo», если вы вошли в систему как root:

В этих системах процесс Nginx называется nginx.

Ваш веб-сервер работает?

Теперь, когда вы уверены, что ваш сервер установлен, он работает?

Существует множество способов узнать, запущена служба или нет. Один из методов, который является довольно кросс-платформенным, заключается в использовании команды netstat.

Это покажет вам все процессы, использующие порты на сервере. Затем мы можем найти имя искомого процесса:

Вы должны изменить «apache2» на имя процесса веб-сервера на вашем сервере. Если вы видите строку, подобную приведенной выше, это означает, что ваш процесс запущен и работает. Если вы не получили никаких результатов, это означает, что вы запросили неправильный процесс или ваш веб-сервер не работает.

В этом случае вы можете запустить его, используя предпочтительный метод вашего дистрибутива. Например, в Ubuntu вы можете запустить службу Apache2, набрав:

В CentOS вы можете ввести что-то вроде этого:

Если ваш веб-сервер запускается, вы можете снова проверить с помощью netstat, чтобы убедиться, что все в порядке.

Правилен ли синтаксис вашего файла конфигурации веб-сервера?

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

Файлы конфигурации для этих служб обычно находятся в подкаталоге каталога /etc/, названного в честь самого процесса.

Таким образом, мы можем попасть в основной каталог конфигурации Apache в Ubuntu, набрав:

Подобным образом каталог конфигурации Apache в CentOS также отражает имя CentOS для этого процесса:

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

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

Если вы используете Apache, вы можете использовать команду apache2ctl или apachectl, чтобы проверить файлы конфигурации на наличие синтаксических ошибок:

Как видно выше, мы получили информационное сообщение о деталях в нашей конфигурации, но ошибок не было. Это хорошо.

Если у вас есть веб-сервер Nginx, вы можете запустить аналогичный тест, набрав:

Как видите, этот процесс также проверяет ваш синтаксис. Если мы удалим конечную точку с запятой из строки в файле (распространенная ошибка для конфигураций Nginx), вы получите следующее сообщение:

Недопустимое количество аргументов, так как Nginx ищет точку с запятой в конце оператора. Если он не находит его, он переходит к следующей строке и интерпретирует это как дополнительные аргументы для последней строки.

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

Открыты ли настроенные вами порты?

Как правило, веб-серверы используют порт 80 для обычного веб-трафика и используют порт 443 для трафика, зашифрованного с помощью TLS/SSL. Для правильного доступа к сайту эти порты должны быть доступны.

Вы можете проверить, открыт ли порт вашего сервера, используя netcat с вашего локального компьютера.

Вам просто нужно использовать IP-адрес вашего сервера и сообщить ему, какой порт вы хотите проверить, например:

Это проверит, открыт ли порт 80 на сервере по адресу 111.111.111.111. Если он открыт, команда вернется сразу. Если он не открыт, команда будет постоянно безуспешно пытаться установить соединение. Вы можете остановить этот процесс, нажав CTRL-C в окне терминала.

Если ваши веб-порты недоступны, проверьте конфигурацию брандмауэра. Возможно, вам потребуется открыть порт 80 или порт 443.

Ваши настройки DNS направляют вас в нужное место?

Если вы можете получить доступ к своему сайту по IP-адресу, но не по доменному имени, возможно, вам следует проверить настройки DNS.

Чтобы посетители могли попасть на ваш сайт через его доменное имя, у вас должна быть запись "A" или "AAAA", указывающая на IP-адрес вашего сервера в настройках DNS. Вы можете запросить запись «A» вашего домена, выполнив следующую команду:

Возвращаемая вам строка должна совпадать с IP-адресом вашего сервера. Если вам нужно проверить запись «AAAA» (для соединений IPv6), вы можете ввести:

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

Если вы используете DigitalOcean, вы можете узнать, как настроить параметры DNS для своего домена, здесь.

Убедитесь, что ваши файлы конфигурации также правильно обрабатывают ваш домен

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

В Apache раздел файла виртуального хоста может выглядеть следующим образом:

Похожий фрагмент в Nginx может выглядеть примерно так:

Этот блок настроен для ответа на тот же тип запроса, который мы обсуждали выше.

Указывает ли корневой каталог документа на расположение ваших файлов?

Другое соображение заключается в том, указывает ли ваш веб-сервер на правильное расположение файла.

Каждый виртуальный сервер в Apache или серверный блок в Nginx настроен так, чтобы указывать на определенный каталог. Если это настроено неправильно, сервер выдаст сообщение об ошибке при попытке доступа к странице.

В Apache корневой каталог документа настраивается с помощью директивы DocumentRoot:

Эта строка сообщает Apache, что файлы для этого домена следует искать в каталоге /var/www/html. Если ваши файлы хранятся в другом месте, вам придется изменить эту строку, чтобы она указывала на правильное место.

В Nginx корневая директива настраивает то же самое:

В этой конфигурации Nginx ищет файлы для этого домена в каталоге /usr/share/nginx/html.

Обслуживает ли ваш веб-сервер правильные индексные файлы?

Если ваш корень документа правильный и ваши страницы индекса не обслуживаются правильно, когда вы переходите на свой сайт или в каталог на вашем сайте, возможно, ваши индексы настроены неправильно.

Когда посетитель запрашивает каталог, ваш сервер обычно хочет предоставить ему индексный файл. Обычно это файл index.html или файл index.php, в зависимости от вашей конфигурации.

В Apache вы можете найти строку в файле вашего виртуального хоста, которая явно настраивает порядок индексации, который будет использоваться для определенных каталогов, например:

Это означает, что при обслуживании каталога Apache сначала будет искать файл с именем index.html и попытается использовать index.php в качестве резервной копии, если первый файл не будет найден.

Вы можете установить порядок, который будет использоваться для обслуживания индексных файлов для всего сервера, отредактировав файл mods-enabled/dir.conf, в котором будут установлены значения по умолчанию для сервера. Если ваш сервер не обслуживает индексный файл, убедитесь, что в вашем каталоге есть индексный файл, соответствующий одному из параметров в вашем файле.

В Nginx директива, которая делает это, называется index и используется следующим образом:

Правильно ли установлены разрешения и права собственности?

Чтобы веб-сервер правильно обслуживал файлы, он должен иметь возможность читать файлы и иметь доступ к каталогам, в которых они хранятся. Это можно контролировать с помощью разрешений и прав собственности на файлы и каталоги.

Для чтения файлов каталоги, содержащие содержимое, должны быть доступны для чтения и выполнения процессом веб-сервера. Имя пользователя и группы, которые используются для запуска веб-сервера, отличаются от дистрибутива к дистрибутиву.

В Ubuntu и Debian и Apache, и Nginx работают от имени пользователя www-data, который является членом группы www-data.

В CentOS и Fedora Apache работает под пользователем с именем apache, который принадлежит к группе apache. Nginx работает под пользователем nginx, который является частью группы nginx.

Используя эту информацию, вы можете просматривать каталоги и файлы, из которых состоит содержимое вашего сайта:

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

Чтобы изменить владельца файла, вы можете сделать следующее:

Это также можно сделать с каталогом. Вы можете изменить владельца каталога и всех файлов в нем, передав флаг -R:

Подробнее о разрешениях в Linux можно узнать здесь.

Ограничиваете ли вы доступ через свои файлы конфигурации?

Возможно, ваши настройки запрещают доступ к файлам, которые вы пытаетесь обслуживать.

В Apache это можно настроить в файле виртуального хоста для этого сайта или в файле .htaccess, расположенном в самом каталоге.

Доступ к этим файлам можно ограничить несколькими способами. Каталоги могут быть ограничены следующим образом в Apache 2.4:

Эта строка указывает веб-серверу не разрешать никому доступ к содержимому этого каталога. В Apache 2.2 и ниже это будет выглядеть так:

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

В Nginx эти ограничения примут форму директив deny и будут расположены в блоках вашего сервера или в основных файлах конфигурации:

Если у вас есть серверная часть базы данных, работает ли она?

Если ваш сайт использует серверную базу данных, такую как MySQL, PostreSQL, MongoDB и т. д., вам необходимо убедиться, что она запущена и работает.

Это можно сделать так же, как вы проверяли, работает ли веб-сервер. Опять же, мы можем искать запущенные процессы, а затем выбирать имя искомого процесса:

Как видите, служба запущена на этом компьютере. При поиске убедитесь, что вы знаете имя, под которым работает ваша служба.

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

Если у вас есть серверная часть базы данных, может ли ваш сайт успешно подключиться?

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

Например, для сайта WordPress настройки подключения к базе данных хранятся в файле с именем wp-config.php . Вам необходимо проверить правильность DB_NAME , DB_USER и DB_PASSWORD, чтобы ваш сайт мог подключиться к базе данных.

Вы можете проверить, содержит ли файл правильную информацию, попытавшись подключиться к базе данных вручную, например:

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

Настроен ли ваш веб-сервер для передачи динамического содержимого обработчику сценариев?

Если вы используете серверную часть базы данных, вы почти наверняка используете язык программирования, такой как PHP, для обработки запросов на динамическое содержимое, извлечения информации из базы данных и отображения результатов.

В этом случае необходимо убедиться, что ваш веб-сервер правильно настроен для передачи запросов обработчику сценариев.

В Apache это обычно означает, что модуль mod_php5 установлен и включен. Вы можете сделать это в Ubuntu или Debian, набрав:

Для систем CentOS/Fedora вам нужно будет ввести:

В Nginx это немного сложнее. У Nginx нет модуля PHP, который можно включить, поэтому нам нужно убедиться, что у нас установлен и включен php-fpm в наших конфигурациях.

На сервере Ubuntu или Debian убедитесь, что компоненты установлены, введя:

В CentOS или Fedora это можно сделать, набрав:

Поскольку обработчик PHP не является частью Nginx, вам нужно указать ему явно передавать файлы PHP. Выполните четвертый шаг этого руководства, чтобы узнать, как настроить Nginx для передачи файлов PHP в php-fpm. Вы также должны взглянуть на часть третьего шага, посвященную настройке процессора PHP. Это должно быть примерно одинаково независимо от вашего дистрибутива.

Если ничего не помогает, снова проверьте журналы

На самом деле проверка журналов должна быть вашим первым шагом, но это также хороший последний шаг перед обращением за дополнительной помощью.

Если вы исчерпали свои возможности самостоятельно устранять неполадки и вам нужна помощь (от друга, через обращение в службу поддержки и т. д.), вы быстрее получите более актуальную помощь, предоставив файлы журнала и сообщения об ошибках. . Опытные администраторы, вероятно, поймут, что происходит, если вы предоставите им необходимую информацию.

Заключение

Надеемся, что эти советы по устранению неполадок помогут вам отследить и устранить некоторые из наиболее распространенных проблем, с которыми сталкиваются администраторы, пытаясь запустить свои сайты.

Если у вас есть какие-либо дополнительные советы по проверке и способам решения проблем, поделитесь ими с другими пользователями в комментариях.

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы.

Нет ничего более разочаровывающего, чем установка Linux на ваш компьютер, и вся система по-прежнему чувствует себя вялой. Потратив деньги на создание, покупку или модернизацию машины, вы ожидаете, что она будет работать быстро. Однако это не всегда так, и с Linux вы можете провести немало исследований, чтобы выяснить, что не так. Сегодня мы покажем вам, как найти причину того, что ваш компьютер с Linux работает слишком медленно.

Почему мой компьютер с Linux работает медленно?

Ваш компьютер с Linux может работать медленно по одной из следующих причин:

Ненужные службы запускаются во время загрузки с помощью systemd (или любой другой системы инициализации, которую вы используете)
Высокое потребление ресурсов из-за открытия нескольких ресурсоемких приложений
Некоторые аппаратные сбои или неправильная конфигурация.

Прежде чем мы узнаем, как мы можем ускорить работу компьютера с Linux, нам нужно знать, какие методы могут помочь нам найти службы, запущенные во время загрузки, процессы, работающие с более высоким или более низким приоритетом, состояние работоспособности ЦП и наличие оперативной памяти. заполнен гораздо большим количеством данных, чем требуется, а также проверить, не заполнена ли область памяти подкачки. Наконец, нам также нужно проверить, хорошо ли работает жесткий диск.

Изучите информацию о ЦП

Если вы хотите ускорить медленный компьютер с Linux, первым делом проверьте информацию о процессоре.Если ваш компьютер не может открыть такую программу, как Firefox или LibreOffice, возможно, это связано с тем, что ваш процессор недостаточно мощный для тяжелых приложений.

Откройте терминал и выполните одну из следующих команд:

Приведенные выше команды отображают подробную информацию о вашем ЦП, такую как vendor_id, название модели, частота ЦП, размер кэша, микрокод и богомипы.

Давайте рассмотрим некоторые важные детали информации о ЦП.

bogomips: означает просто поддельные миллионы инструкций в секунду. Это отдельная программа, которая отображает производительность вашей системы.
имя_модели: имя_модели указывает производителя, модель и скорость процессора. В данном случае у нас есть процессор Intel(R) Celeron(R) с тактовой частотой 1,73 ГГц.
Cpu MHZ: cpu MHZ (мегагерц) используется для измерения скорости передачи каналов, шин и внутренних часов компьютера. В этом случае скорость передачи составляет 1733,329 ГГц.

Здесь мы ясно видим проблему: процессор Intel Celeron с частотой 1,73 ГГц — старый процессор с небольшой вычислительной мощностью. Это одноядерный ЦП, работающий на низкой скорости, в то время как многие новые ЦП имеют 16 ядер с тактовой частотой почти 5 ГГц.

Также прочтите: Использование файловой системы /proc для изучения внутренней работы Linux

Решение

Если у вас старый и медленный процессор, единственное решение – заменить его на более новый. Узнайте, на что нужно обращать внимание при покупке нового процессора.

Проверка служб, запущенных во время загрузки

Существуют различные способы проверки запуска служб во время загрузки. Вы можете использовать любую из следующих команд.

Эта команда выводит список служб, запущенных во время загрузки:

Эта команда выводит список служб, запущенных во время загрузки. Он совместим с CentOS, AlmaLinux, Fedora и RHEL:

Эта команда также выводит список служб, запущенных во время загрузки:

initctl — это инструмент управления демоном, который позволяет системному администратору общаться и взаимодействовать с демоном Upstart.

Если в вашей системе используется systemd, вы можете использовать следующую команду, чтобы найти службы, которые запускаются во время загрузки:

Решение

Для дистрибутива Linux, использующего systemd, вы можете использовать команду systemctl для управления вашими службами, чтобы они не запускались во время загрузки.

Проверить загрузку процессора

Помимо проверки служб, запущенных во время загрузки, вы также можете проверить, не перегружен ли ваш процессор/процессор процессами. Вы можете использовать команду top или любой из этих инструментов мониторинга системы, чтобы проверить загрузку ЦП.

Команда top сортирует процессы с наибольшим использованием сверху. Как вы можете видеть на снимке экрана ниже, вы можете четко определить, какой процесс/приложение злоупотребляет вашим процессором, и при необходимости убить его с помощью команды kill.

Решение

Если у вас запущено слишком много приложений (как на переднем плане, так и в фоновом режиме) и ваш ЦП не на должном уровне, лучше всего закрыть приложения, которые вы не используете. Кроме того, отключите все неиспользуемые приложения, работающие в фоновом режиме.

Кроме того, вы можете использовать предварительную загрузку для загрузки часто используемых приложений. Preload — это демон, работающий в фоновом режиме и анализирующий часто запускаемые приложения.

Откройте терминал и выполните следующую команду:

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

Проверить наличие свободного места в памяти

Оперативная память — это место, где обычно хранятся часто используемые приложения. Вы можете использовать команду free для проверки информации о памяти, такой как свободное место для ОЗУ и т. д. Меньший объем памяти также может повлиять на производительность компьютера.

Решение

Либо обновите оперативную память, либо замените приложения, интенсивно использующие память, облегченными альтернативами.Такие приложения, как Libreoffice, довольно требовательны к памяти. Вместо LibreOffice вы можете использовать Abiword.

Проверьте, не перегружен ли ваш жесткий диск

У вас постоянно горит индикатор жесткого диска, но вы понятия не имеете, что он делает? Загадочный ввод/вывод может быть проблемой, поэтому существует популярный инструмент под названием iotop, специально предназначенный для диагностики такого рода проблем.

Откройте терминал и введите команду:

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

Однако если вы запустите утилиту, интенсивно использующую диск, например find, вы увидите ее имя и пропускную способность, четко указанные в iotop .

Теперь вы можете легко узнать, какая программа использует ваш ввод-вывод, кто ее запустил, скорость чтения данных и многое другое.

Заключение

Хотя существует множество причин, которые потенциально могут вызвать замедление работы системы, подавляющее большинство проблем с производительностью связаны с ЦП, ОЗУ и дисковым вводом-выводом. Использование описанных здесь методов поможет вам определить причину проблем с производительностью и способы их устранения.

Следующее, что вы можете сделать, это ускорить работу вашей системы Ubuntu. Если у вас также возникают проблемы с Wi-Fi, ознакомьтесь с этим руководством, чтобы решить проблему с Wi-Fi, которая не работает в Linux.

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

Взять верх

Команда top в Linux предоставляет множество информации по устранению неполадок, но вы должны знать, что ищете. Ссылайтесь на эту схему при выполнении следующих шагов:

Шаг 1. Проверьте ожидание ввода-вывода и время простоя ЦП

Как: используйте top — ищите "wa" (ожидание ввода-вывода) и "id" (время простоя ЦП)

Почему: проверка ожидания ввода-вывода – лучший начальный шаг для выявления первопричины медленной работы сервера. Если время ожидания ввода-вывода мало, вы можете исключить доступ к диску в своей диагностике.

Ожидание ввода-вывода представляет собой время, в течение которого ЦП ожидает дискового или сетевого ввода-вывода. Ключевым моментом здесь является ожидание — если ваш процессор ждет, он не выполняет полезную работу. Это как шеф-повар, который не может подать еду, пока не получит ингредиенты. Все, что превышает 10 % ожидания ввода-вывода, следует считать высоким.

С другой стороны, время простоя ЦП — это показатель, который вы ХОТИТЕ иметь высоким. Чем он выше, тем больше пропускная способность вашего сервера для обработки всего, что вы на него набрасываете. Если время простоя постоянно превышает 25 %, считайте его «достаточно высоким»

Шаг 2. Ожидание операций ввода-вывода мало, а время простоя мало: проверьте время использования ЦП

Как: снова используйте top – найдите столбец %us (первый столбец), а затем найдите процесс или процессы, которые наносят ущерб.

Почему: в этот момент вы ожидаете, что процент пользовательского времени будет высоким. Скорее всего, это программа или служба, которую вы настроили на своем сервере и которая перегружает ЦП. Проверка % пользовательского времени только подтверждает это. Когда вы видите, что % usertime высок, пришло время посмотреть, какой исполняемый файл монополизирует ЦП

Убедившись, что % пользовательского времени высок, проверьте список процессов (также предоставленный top). По умолчанию top сортирует список процессов по %CPU, поэтому вы можете просто просмотреть процесс или процессы, находящиеся в самом верху.

Если есть один процесс, нагружающий ЦП таким образом, который кажется ненормальным, это ненормальная ситуация, которую можно исправить перезапуском службы. Если есть несколько процессов, использующих ресурсы ЦП, или есть один процесс, который потребляет много ресурсов, но в остальном работает нормально, то ваша установка может быть недостаточно мощной. Вам нужно будет обновить свой сервер (добавить больше ядер) или разделить службы на другие блоки. В любом случае у вас есть решение:

если ситуация кажется аномальной: убейте нарушающие процессы.
если ситуация кажется типичной с учетом истории: обновите сервер или добавьте больше серверов.

Это область, в которой исторический контекст может очень помочь в понимании того, что происходит. Если вы используете Scout, ознакомьтесь с историческими диаграммами для этих показателей. Плоская линия для % пользовательского времени, сопровождаемая огромным увеличением за последние 10 минут, говорит совсем о другом, чем плавный, устойчивый рост за последние 6 месяцев.

Шаг 3. Время ожидания операций ввода-вывода мало, а время простоя велико

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

начните с проверки важных приложений на нехарактерную медлительность (для начала подойдет БД),
подумайте, какие части вашей инфраструктуры могут быть замедлены извне. Например, используете ли вы внешнюю службу электронной почты, которая может замедлять работу важных частей вашего приложения?

Если вы подозреваете, что в вашем кластере есть другой сервер, strace и lsof могут предоставить информацию о том, что процесс делает или ожидает. Strace покажет вам, какие файловые дескрипторы считываются или записываются (или из которых предпринимаются попытки чтения), а lsof может предоставить сопоставление этих файловых дескрипторов с сетевыми подключениями.

Шаг 4. Ожидание ввода-вывода слишком велико: проверьте использование подкачки

Как: используйте top или free -m

Почему: если ваш компьютер часто выгружается на диск, подкачки кеша монополизируют диск, и процессы с законными потребностями ввода-вывода будут испытывать нехватку доступа к диску. Другими словами, проверка подкачки диска отделяет «настоящие» проблемы ожидания ввода-вывода от проблем с оперативной памятью, которые «выглядят как» проблемы ожидания ввода-вывода.

Альтернативой top является free -m. Это полезно, если вам не нравятся частые обновления top, и у вас нет консольного журнала изменений.

Шаг 5: высокий уровень использования подкачки

Высокое использование подкачки означает, что вам фактически не хватает оперативной памяти. См. шаг 6 ниже.

Шаг 6. Использование подкачки низкое

Низкий объем подкачки означает, что у вас есть "настоящая" проблема с ожиданием ввода-вывода. Следующий шаг — выяснить, что мешает вашему вводу-выводу.

Как: iotop

iotop – отличный инструмент для выявления нарушителей правил io. Обратите внимание на две вещи:

если вы еще не установили iotop, вероятно, его еще нет в вашей системе. Рекомендация: устанавливайте его до того, как он вам понадобится: неинтересно пытаться установить инструмент для устранения неполадок на перегруженную машину.
для iotop требуется Linux версии 2.62 или выше

Шаг 7. Проверьте использование памяти

Как: используйте top. После запуска top нажмите клавишу M — это отсортирует приложения по используемой памяти.

После того как вы определили нарушителей, решение снова будет зависеть от того, кажется ли их использование памяти обычным или нет. Например, утечку памяти можно устранить однократным или периодическим перезапуском процесса.

если использование памяти кажется аномальным: завершите процессы, вызывающие нарушение.
если использование памяти кажется обычным делом: добавьте ОЗУ на сервер или разделите верхнюю часть памяти с помощью служб на другие серверы.

Дополнительные советы

vmstat также является очень удобным инструментом, поскольку он показывает прошлые значения, а не обновление на месте, как top. Запуск vmstat 1 показывает краткие показатели памяти, подкачки, операций ввода-вывода и ЦП каждую секунду.
Отслеживайте задержку дискового ввода-вывода и сравнивайте ее с IOPS (операций ввода-вывода в секунду). Иногда это не активность на вашем собственном сервере, что приводит к замедлению дискового ввода-вывода в облачной/виртуальной среде. Доказать это сложно, и вам очень нужны графики исторической эффективности, чтобы показать вашему провайдеру!
Увеличение задержки ввода-вывода может означать неисправность диска или поврежденных секторов. Следите за этим, прежде чем это приведет к повреждению данных или полному отказу диска.

Если у вас под рукой будут конкретные шаги, устранение неполадок с медленным сервером станет немного проще. Top — это мощный инструмент, который предоставляет множество метрик, помогающих сузить круг причин медленной работы сервера. Метрики, на которые вы будете смотреть, это ожидание ввода-вывода, процент простоя процессора, процент пользователя, свободная память (с учетом файлового кеша) и использование подкачки. В зависимости от того, являются ли проблемы разовыми или результатом растущих требований к вашей инфраструктуре, вы можете решить проблему замедления, перезапустив службы, или вам может потребоваться обновить серверы.

Больше серверов? Или более быстрый код?

Добавление серверов может помочь при медленном коде. Scout APM поможет вам найти и исправить неэффективный и дорогостоящий код. Мы автоматически выявляем вызовы N+1 SQL, нехватку памяти и другие проблемы, связанные с кодом, поэтому вы можете тратить меньше времени на отладку и больше времени на программирование. У нас есть агенты Ruby, Python и Elixir.

Готовы оптимизировать свой сайт? Зарегистрируйтесь для получения бесплатной пробной версии.

Возможно, одна из самых распространенных проблем, с которыми вы столкнетесь в системе, заключается в том, что она очень медленно перестает отвечать на запросы. Часто это может быть вызвано проблемами с сетью, но в этом руководстве мы обсудим некоторые локальные шаги по устранению неполадок, которые вы можете использовать, чтобы понять разницу между сетью и компьютером.

Если компьютер тормозит, это часто происходит из-за того, что вы израсходовали все определенные ресурсы в системе. Основными системными ресурсами являются ЦП, ОЗУ, дисковый ввод-вывод и сетевая статистика.Из-за чрезмерного использования любого из этих ресурсов система может увязнуть до такой степени, что часто вам нужно будет только быстро перезагрузить систему. Если вы можете войти в систему, вы можете использовать ряд инструментов для определения основной причины.

Загрузка системы

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

Три числа после средней нагрузки — 2,01, 20,15 и 15,07 — представляют собой средние значения нагрузки на машину за 1, 5 и 15 минут соответственно. Средняя загрузка системы обычно равна среднему количеству процессов в работоспособном или бесперебойном состоянии. Запускаемые процессы либо используют ЦП, либо ожидают, а непрерываемые процессы ожидают ресурсов ввода-вывода.

Система с одним ЦП со средней нагрузкой 1 означает, что один ЦП находится под постоянной нагрузкой. Если эта однопроцессорная система имеет среднюю загрузку 3, нагрузка на систему в три раза больше, чем она может выдержать, поэтому два из трех процессов ожидают ресурсов. Таким образом, средняя загрузка системы не может быть изменена в зависимости от количества имеющихся у вас ЦП, поэтому, если у вас есть система с двумя ЦП со средней загрузкой 1, один из ваших двух ЦП всегда загружен, т. е. у вас 50% нагрузка. Таким образом, нагрузка 1 в системе с одним ЦП такая же, как нагрузка 4 в системе с четырьмя ЦП с точки зрения количества доступных ресурсов.

Что такое высокая средняя нагрузка?

Справедливый вопрос, когда средняя нагрузка считается высокой. Короткий ответ: «Это зависит от того, что вызывает это». Поскольку нагрузка описывает среднее количество активных процессов, использующих ресурсы, всплеск нагрузки может означать несколько вещей. Важно определить, является ли нагрузка привязкой к ЦП (процессы, ожидающие ресурсов ЦП), привязкой к ОЗУ (в частности, высокая загрузка ОЗУ, перемещенная в подкачку) или привязкой к вводу-выводу (процессы, борющиеся за дисковый или сетевой ввод/вывод). О).

Обычно системы кажутся более отзывчивыми при нагрузке, связанной с ЦП, чем при нагрузке, связанной с вводом-выводом. Мы видели более ранние системы с сотнями загрузок, привязанных к ЦП, и мы все еще могли запускать диагностические инструменты на этих системах с хорошим временем отклика. Принимая во внимание, что мы видели системы с относительно низкой нагрузкой, связанной с вводом-выводом, в которых мы только что пытались войти в систему, занимали минуты, потому что дисковый ввод-вывод был полностью насыщен. Если системе часто не хватает ресурсов ОЗУ из-за нагрузки, связанной с вводом-выводом, поскольку система начинает использовать хранилище подкачки на диске, это может потреблять ресурсы диска и замедлять процессы.

Диагностика проблем с загрузкой с помощью команды top

Одним из первых инструментов, который я предпочитаю для диагностики высокой нагрузки, является top. Когда вы наберете top в командной строке и нажмете Enter, вы сразу увидите много системной информации. Эти данные постоянно обновляются, так что вы видите оперативную информацию о системе, включая время безотказной работы системы, среднюю загрузку, общее количество процессов, запущенных в системе, и объем доступной вам памяти — всего, используемой и свободной — и, наконец, список процессы в системе и сколько ресурсов они используют. Вы, вероятно, не сможете увидеть каждый процесс, который в данный момент работает в вашей системе, с помощью top, потому что они не все поместятся на экране. По умолчанию вверху отображаются процессы в зависимости от того, сколько процессорного времени они используют.

Что делать, если вы заметили, что процесс потребляет все ресурсы ЦП, и вам нужно его остановить? Первый столбец для процессов в верхнем выводе помечен как PID (идентификатор процесса) и показывает идентификатор процесса программы — уникальный номер, присвоенный каждому процессу в системе. Чтобы убить процесс, нажмите клавишу K на клавиатуре, а затем введите PID, который вы хотите убить. Затем нажмите Enter, когда будет предложено убить сигналом 15.

Команда Top по умолчанию запускается в интерактивном режиме, и это нормально, если вы не хотите просматривать информацию, которая не помещается на экране. Если вы хотите просмотреть полный вывод команды top или перенаправить его в файл, вы можете запустить его в пакетном режиме. Параметр -b предназначен для пакетного режима, а параметр -n позволяет указать, сколько раз будет обновляться top перед его закрытием.

Если вам нужно одновременно просмотреть верхний вывод и перенаправить вывод в файл, вы можете использовать удобный инструмент командной строки tee:

Обоснуйте выходные данные верхней команды

После того как вы используете команду top для диагностики нагрузки, основные шаги заключаются в проверке выходных данных верхнего уровня, чтобы определить, какие ресурсы у вас заканчиваются ЦП, ОЗУ или дисковым вводом-выводом). Выяснив это, вы можете попытаться определить, какие процессы потребляют эти ресурсы больше всего.

Первая строка вывода такая же, как и в команде uptime. Как видите, машина не слишком загружена для четырехпроцессорной машины:

Команда Top предоставляет дополнительные показатели помимо стандартной загрузки системы. Например, строка Cpu(s) показывает вам информацию о том, что процессоры в данный момент делают:

В предыдущем примере вы видели, что система простаивает более чем на 50 %, что соответствует нагрузке 1,70 в системе с четырьмя ЦП. При диагностике медленной системы одним из первых значений, на которое следует обратить внимание, является ожидание ввода-вывода, чтобы исключить дисковый ввод-вывод.

Если время ожидания ввода-вывода меньше, вы можете посмотреть на процент простоя.
Если ожидание операций ввода-вывода слишком велико, следующим шагом будет диагностика причины высокой скорости ввода-вывода на диске, которую мы сейчас рассмотрим.
Если ожидание ввода-вывода и время простоя невелики, вы, скорее всего, увидите высокий процент времени пользователя, поэтому вам необходимо определить причину этого.
Если время ожидания ввода-вывода меньше, а процент простоя высок, то вы знаете, что медлительность не связана с ресурсами ЦП, и вам придется начать устранение неполадок в другом месте.

Диагностика большого количества времени пользователя

Распространенной проблемой является диагностика высокой нагрузки из-за высокого процента процессорного времени пользователя. Это наиболее распространенная проблема, поскольку службы на вашем компьютере берут на себя основную часть системной нагрузки и являются пользовательскими процессами. Если вы наблюдаете высокую загрузку ЦП пользователя, но низкое время ожидания ввода-вывода, вам необходимо определить, какие процессы в системе потребляют больше всего ЦП. По умолчанию top сортирует все процессы по загрузке ЦП:

Здесь В этом примере процесс mysqld потребляет 54 % ресурсов ЦП, а процесс nagios2db_status — 13 %. Обратите внимание, что это процент одного ЦП, поэтому, если у вас есть машина с четырьмя ЦП, вы можете увидеть больше процессов, потребляющих 99% ЦП.

Наиболее распространенные ситуации с высокой загрузкой ЦП, которые вы можете наблюдать, например, когда все ЦП потребляются одним или двумя процессами или большим количеством процессов. В этом случае, чтобы решить проблему, вы можете просто убить процесс, потребляющий ЦП (нажмите K и затем введите номер PID для процесса).

В случае нескольких процессов одна система может выполнять слишком много задач. Например, у вас может быть большое количество процессов Apache, работающих на веб-сервере, а также некоторые сценарии разбора журнала, которые запускаются с использованием cron. Все эти процессы могут потреблять более или менее одинаковое количество ЦП. Решение этих проблем может быть более сложным в долгосрочной перспективе. Как и на веб-сервере, вам нужно, чтобы все эти процессы Apache работали, но вам также могут понадобиться программы для анализа журналов. В краткосрочной перспективе вы можете остановить (или, возможно, отложить) некоторые процессы до тех пор, пока нагрузка не уменьшится, но в долгосрочной перспективе вам, возможно, придется подумать об увеличении ресурсов вашего компьютера или распределении некоторых функций между несколькими серверами.

Диагностика проблем с нехваткой памяти

В следующих двух строках верхнего вывода команды отображается ценная информация об использовании ОЗУ. Перед диагностикой конкретных системных проблем важно исключить проблемы с памятью.

Первая строка показывает, сколько физической оперативной памяти доступно, используется, свободно и буферизовано. Вторая строка описывает нам аналогичную информацию об использовании подкачки, а также о том, сколько оперативной памяти используется файловым кешем Linux. Сначала может показаться, что на машине почти закончилась оперативная память, поскольку машина сообщает, что свободно только 26 768 КБ. Большинство специалистов по устранению неполадок вводят в заблуждение используемую и свободную оперативную память из-за файлового кеша Linux. Как только Linux загружает файл в ОЗУ, он не обязательно удаляет его из ОЗУ, когда программа завершает работу с ним. Если есть доступная оперативная память, Linux будет кэшировать файл в оперативной памяти, чтобы, если программа снова обращается к файлу, она могла сделать это намного быстрее. Если системе требуется оперативная память для активных процессов, она не будет кэшировать столько файлов.

Диагностика высокого ожидания ввода-вывода

Когда вы сталкиваетесь с проблемой большого количества ожиданий операций ввода-вывода, в первую очередь следует проверить, не использует ли машина много операций подкачки. Поскольку жесткий диск работает медленнее, чем оперативная память, и когда системе не хватает оперативной памяти и она начинает использовать подкачку на вашем сервере, производительность сервера снижается. Все, что хочет получить доступ к диску, должно конкурировать с свопом за дисковый ввод-вывод. Таким образом, вы сначала диагностируете, не хватает ли вам памяти, и если да, то решаете проблему там. Если на вашем сервере достаточно оперативной памяти, вам необходимо выяснить, какая программа получает больше всего операций ввода-вывода. Иногда бывает трудно определить, какой именно процесс занимает больше всего операций ввода-вывода, но если в вашей системе несколько разделов, вы можете сузить круг поиска, выяснив, на какой раздел приходится большая часть операций ввода-вывода. Для этого вам понадобится программа iostat, входящая в состав пакета sysstat как в системах на основе RedHat, так и в системах на базе Debian. если он не установлен, вы можете установить его с помощью менеджера пакетов.

вы можете запустить команду iostat без каких-либо аргументов, чтобы увидеть общую картину вашей системы:

В первой строке вывода содержится информация о ЦП, аналогичная той, что вы видите вверху. Вот что представляет каждый из столбцов:

tps — показывает количество передач, т. е. запросов ввода-вывода, отправленных на устройство в секунду на устройство.
Blk_read/s — в этом столбце показано количество блоков, считанных с устройства в секунду.
Blk_wrtn/s — в этом столбце показано количество блоков, записываемых на устройство в секунду.
Blk_read – в этом столбце показано общее количество блоков, считанных с устройства.
Blk_wrtn — в этом столбце показано общее количество блоков, записанных на устройство.

Когда вы сталкиваетесь с проблемой высокой нагрузки ввода-вывода в вашей системе, первым делом нужно просмотреть каждый из разделов и определить, какой раздел получает наибольшую нагрузку ввода-вывода. Скажем, например, что у вас есть сервер базы данных, а сама база данных хранится в /dev/sda3. Если вы видите, что основная часть операций ввода-вывода поступает оттуда, у вас есть хорошее представление о том, что база данных, вероятно,
потребляет операции ввода-вывода.

Помимо iostat, у нас есть еще один гораздо более простой инструмент, доступный в более новых дистрибутивах, который называется iotop. По сути, это комбинация top и iostat, которая показывает вам все запущенные процессы в системе, отсортированные по их статистике ввода-вывода. Вы можете запустить iotop от имени пользователя root и увидеть результат, подобный следующему:

В этом примере вы можете ясно видеть, что процесс rsync связывает ваш ввод-вывод при чтении.

Читайте также: