- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день!
на сервере возникла проблема:
за последние 2 дня load averages стал зашкаливать за 15-20,
хотя до этого никогда всегда был 1-2!
это приводит к выключению системы, приходится перегружать
ничего не менялось, в логах ничего подозрительного нет,
только потихоньку обновлялась база работниками,
починил все таблицы, оптимизировал, все равно 0 результата,
в чем может быть проблема?
P.S. отключаю mysqld - load averages сразу становятся 0.8-1.2
top показывает 15-25 активных процессов, около 500 sleeping
(т.к. используется pconnect)
может, руткит какой забрался?
как это проверить?
руткиты хорошо ищет rkhunter
P.S. отключаю mysqld - load averages сразу становятся 0.8-1.2
top показывает 15-25 активных процессов, около 500 sleeping
(т.к. используется pconnect)
может, руткит какой забрался?
как это проверить?
Да не, скорее тут все же в mysql дело. Попробуйте долгие запросы пологировать
проверить три весчи
1. объём базы какой ? может там уже сотни тысяч записей в табличках
2. Закрываются ли транзакции ?
3. а зачем вообще тама постоянный коннект . :)
Вобщем на самом деле потрясите программеров .. что они ещё раз прошли по коду ..
show full processlist в студию.
это приводит к выключению системы, приходится перегружать
Достаточно перезапустить mysql.
ничего не менялось, в логах ничего подозрительного нет, только потихоньку обновлялась база работниками, починил все таблицы, оптимизировал, все равно 0 результата,
в чем может быть проблема?
mytop поможет увидеть запросы в реальном времени.
Проблема мб в pconnect-ах или большом притоке пользователей.
P.S. отключаю mysqld - load averages сразу становятся 0.8-1.2
top показывает 15-25 активных процессов, около 500 sleeping
(т.к. используется pconnect)
Уберите pconnect-ы и посмотрите что изменится.
Бывает, что из-за их использования число соединений растёт. А каждое, даже спящее, соединение требует для себя выделения буферов. При sleeping соединениях скорее всего была съедена вся память и mysql ушла в своп. Из него она может и не вернуться без перезапуска (так как запросы продолжают поступать).
Как вариант, можно уменьшить количество соединений на пользователя или на всю базу вцелом. Но если проблема в pconnect-ах, то от этого она только рашьше отрубится.
Ещё вариант - написать скриптик, который будет анализировать show process list и убивать долго спящие процессы. Так сделал один мой знакомый, у него работает. Хотя можно и через my.cnf это решить.
базы в сумме около 100 Мб,
самое большое кол-во рядов 33000, остальные по 5000-10000...
свободной памяти около 1 Гб,
своп свободен всегда, судя по top
"show full processlist в студию."
состоит из слипов в основном :( длительностью от 0 до 20 секунд,
т.к. в my.cnf стоит умирание через 20 сек
pconnect убрал, ничего не изменилось...
load averages бешеные, до 50 доходит...
(Xeon 2.8 2Gb ram)
прирост юзеров тоже нехилый, но раньше выдерживал и больше раза в полтора...
отрубил в php.ini persistent connection
после ребута толку 0, так же куча слип процессов очень длинных
в скриптах подключения к базе проставил connect вместо pconnect,
после ребута то же самое
посмотрел длинные процессы, select count(id) from table
из 33000 рядов выбирает 24 секунды O_o
вообще не понимаю, что такое...
еще интересный момент:
отключаю один сайт от одной базы (10000 записей, около 7 метров)
load averages сразу паадет до нормальных 1-2...
хотя на этом сайте не так много человек по сравнению с остальными...
скрипты точно не менялись, ни одна строчка, в базу добавлений не было (!)
все, что можно , с базой сделал...
все равно толку 0...
query_cache_size = 128M
стоит 256M...
-----------------------------
в итоге оказалось , что сервер нагружал запрос, который с базой в 3 раза больше
работает нормально... избавился от него ...
только до сих пор не понятно, почему это произошло в один из обычных дней,
хотя до этого все работало нормально даже при большем количестве хостов...
Спасибо Вам за советы!
Нередко бывают ситуации, когда некоторые из параметров - количество строк в таблицах, фрагментированность страниц, объем таблиц - пересекают явные или неявные пороги, такие как размеры кэша или буферов, в результате чего резко падает производительность либо из-за того, что выбранные сервером БД стратегии работы с данными перестают быть эффективными, либо сервер сам ошибочно меняет стратегию на менее эффективную.