- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Характеристики сервера:
Core i7-3770 CPU @ 3.40GHz 1600.000 Mhz X 8.
RAM 8 GB.
RAID1 (soft).
Установлен Apache (prefork.c). Базы MySQL находятся на SSD.
Nginx нет.
На прошлой неделе вырубился сервер на пару часов. Его запустили, все заработало нормально. Но что-то оказалось не так.
Если смотреть на munin, то заметна белая полоса - это период, когда отключился.
Посещаемость как была прежде высокой, такой же осталась. Вот только изменилась нагрузка на сервер до и после отключки. Она стала расти.
Это стало заметно по росту количества процессов apache. В логах стало часто появляться следующее сообщение: "server reached MaxClients setting, consider raising the MaxClients setting".
Изначально, было установлено 150. Пробовали увеличивать и увеличили еще немного до 200. Но процессы продолжают плодиться.
DDOS нету. По Apache-status можно видеть довольно много "OPTIONS * HTTP/1.0 ".
С помощью atop выяснилось, что у sda и sdb значение busy в среднем 70%.
Свободного места на рейде - 52% (df -m).
Данные по дискам - smartctl - sda и sdb.
Диски Seagate и здесь на Серче один отписывал, что у дисков этой компании всегда такие значения по Error_Rate.
Данные smartctl -a /dev/sda:
Данные smartctl -a /dev/sdb:
Данные smartctl -H /dev/sda и /sdb - PASSED.
По серверам я не профи, поэтому много чего не знаю и стараюсь лишнего не делать, неизвестных мне команд не вводить, не экспериментировать. Прежде чем что-то сделать, стараюсь по максимуму загуглиться и найти необходимую информацию.
Вот нашел чей-то пост на специализированном форуме, где ситуация по большей степени схожа с моей. Но возможно и ошибаюсь.
Апач плодит процессы, и нагружает iowait, %wa в top-е где-то 60-80%, iotop показывает 15-40 процессов апача, каждый из которых «пользует» диск на 60-99%. Соответственно, все тупит и лежит. Иногда это происходит, когда диск нагружают «тяжелые» дисковые операции, например, ротейт, бекапы, пересчет квоты, но иногда эти же операции апач не валят, т.е. без видимых причин. Четкой зависимости обнаружить не удалось.
Что делали: Вынесли пользовательские данные на отдельный винчестер, отключили журнал. Вынесли mysql базы на отдельный ssd. Уменьшили ionice для ротейта, бекапов. Обновили httpd-itk с 2.2.23 на 2.2.24. В целом принятые меры немного помогли, все работает ровно, но только до начала работы процесса с большой дисковой нагрузкой (см. выше). Так же стоит сказать, что диск с пользовательскими данными - обычный десктопный винчестер на 7200 оборотов и с кэшем 16 МБ.
Система centos 6.4, i5, 12 ГБ ОЗУ. httpd-itk установлен из CentALT Перед апачем стоит nginx. На сервере около 1200 сайтов, в основном простые и с небольшой посещаемостью (а то и вовсе без посещаемости). Средний LA в обычные вечера (т.е. когда нет описанного выше скачка нагрузки) - около 2-2.5, средний %wa - 1-10%.
<IfModule itk.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 78 MaxClients 78 MaxRequestsPerChild 1000 </IfModule>
Чуть раньше MaxClients и ServerLimit был 256 и в моменты наступления проблемы LA возростал до 150(!), после расчета и выставления 78 ЛА стал доходить до 35, тупить 5-10 минут и возвращаться в нормальное состояние.
По форумам таких тем масса, но четкого и однозначного решения нет.
В чем проблема, в каком направлении копать? С апачем, который валится при малейшей нагрузке или же с дисковой подсистемой?
Источник поста.
Помогите определить, с чем может быть это связано. С диском или же апаче? Или это контроллер, или программный рейд?
По тому же треду, что в последней цитате - ТС пишет, что это связано с наплывом ботов от Яндекса.
Хостер как раз тоже мне об этом писал, что довольно много ботов. Только нагрузка в первый раз так растет и не спадает. Причем тенденция заметна после простоя. Можно ли это как-то проверить?
cat /proc/mdstat
Возможно у Вас развалился массив, вот и перестраивается.
Вот данные. Вроде все норм, если не ошибаюсь.
По инодам, df -i, тоже все ок. Много свободных, 99%.
iotop -oPa покажите еще
и оперативку (htop), мб все засвопалось просто
и очередь exim, sendmail проверьте, мб там море писем пытается отправить.
apache плодится из за большого кол-ва соединений. Далее уже идёт нагрузка на диск от него и от Mysql.
Ну и как следствие растёт la. Установите перед apache nginx, настройте отдачу статики через него,
также подумайте о кэшировании. Смотрите запросы, от кого они идут (ip, user-agent и прочее).
По возможности ограничьте их, воспользуйтесь Crawl-delay.
Если это вовсе не боты поисковых системы, то можно их полностью отсечь
apache плодится из за большого кол-ва соединений. Далее уже идёт нагрузка на диск от него и от Mysql.
Ну и как следствие растёт la. Установите перед apache nginx, настройте отдачу статики через него,
также подумайте о кэшировании. Смотрите запросы, от кого они идут (ip, user-agent и прочее).
По возможности ограничьте их, воспользуйтесь Crawl-delay.
Если это вовсе не боты поисковых системы, то можно их полностью отсечь
mysql же на ssd, какая от него нагрузка
iotop -oPa покажите еще
и оперативку (htop), мб все засвопалось просто
и очередь exim, sendmail проверьте, мб там море писем пытается отправить.
iotop -oPa
htop
По поводу nginx - трафик был таким же неделю назад и две, но la было на минимуме и не было такой нагрузки на голом apache. Началось после остановки сервера, хотя не знаю, может ли быть это определенным фактором.
Насчет спама - куча писем шло на прошлой неделе, несколько сотен пришло вроде. exim, sendmail сейчас проверю.
Поставьте nginx и проксируйте на apache.
Для apache установите mod_rpaf и выключите KeepAlive
Конфиг my.cnf покажите
Есть стата munin по mysql?
Напишите ссылку на munin
В syslog или messages - нет ошибок связанных с дисками(ATA) ?
Дисков у вас сколько?
По смарту - 2 SATA
Есть третий?
С my.cnf все нормально. Он был настроен под нагрузку плюс mysql на ssd. Мунина по mysql нету.
Nginx с .htaccess не дружит, а их очень много и важных.
Много айпишников поисковых ботов. В-общем, видимо, поселился их целый полк на сервере после отключки.
Сегодня еще посмотрят, что да как.
С my.cnf все нормально. Он был настроен под нагрузку плюс mysql на ssd. Мунина по mysql нету.
Nginx с .htaccess не дружит, а их очень много и важных.
Много айпишников поисковых ботов. В-общем, видимо, поселился их целый полк на сервере после отключки.
Сегодня еще посмотрят, что да как.
Nginx только проксирует.
.htaccess так и будет обрабатывать apache
Согласно данным, засеченным лишь за 1 секунду на server-status, 23 Яндекс.Бота (по ip их меньше), 9 Google Ботов и 2 msn-бота шерстят 52 урла (52 процесса). Некоторые боты шерстят по две страницы в секунду на одном сайте, хотя по crawl-delay должна быть пауза. WTF?
Их может быть больше, т.к. еще 23 процесса содержали "OPTIONS * HTTP/1.0".
Причем нагрузка была не особо "большая".
За 4 минут - 150 MB отдано. Получается, за час - 2,25 GB уходит примерно.