Большой LA на неработающем сервере

А чо у тебя неймед обслуживает? Он не должен вообще так себя вести. Даже под большой нагрузкой.

ну давай тогда лог что в messages?

Может неймед старый, на его ддосят на уязвимость. Обновить его надо.

Pentarh писал:

Может неймед старый, на его ддосят на уязвимость. Обновить его надо.

зачем гадать, сейчас лог скинет и там станет более-менее ясно, скорее всего проблема с dnssec

AWD писал:

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

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

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

....

Последний раз редактировалось: Bond James (04/03/13 в 01:32), всего редактировалось 1 раз

Через жопу настроены master/slave зоны. Но это едва ли может являться причиной нагрузки.

Обнови неймед.

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

Код:

Feb 22 13:16:21 lcwmlw1126 named[3383]: 03641f096ea0ceb02e407a63ea6d9e42d7ceafabd8156336551aeae23ee060ed.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/localhost_resolver: sync_keyzone:dns_journal_open -> unexpected error Feb 22 13:16:21 lcwmlw1126 named[3383]: 3bed2cb3a3acf7b6a8ef408420cc682d5520e26976d354254f528c965612054f.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/internal: sync_keyzone:dns_journal_open -> unexpected error Feb 22 13:16:21 lcwmlw1126 named[3383]: 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/external: sync_keyzone:dns_journal_open -> unexpected error

ibiz писал:

думаю надо проанализировать эти ошибки получше, возможно в них кроется проблема Код: Feb 22 13:16:21 lcwmlw1126 named[3383]: 03641f096ea0ceb02e407a63ea6d9e42d7ceafabd8156336551aeae23ee060ed.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/localhost_resolver: sync_keyzone:dns_journal_open -> unexpected error Feb 22 13:16:21 lcwmlw1126 named[3383]: 3bed2cb3a3acf7b6a8ef408420cc682d5520e26976d354254f528c965612054f.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/internal: sync_keyzone:dns_journal_open -> unexpected error Feb 22 13:16:21 lcwmlw1126 named[3383]: 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys.jnl: create: permission denied Feb 22 13:16:21 lcwmlw1126 named[3383]: managed-keys-zone/external: sync_keyzone:dns_journal_open -> unexpected error

Ошибки исправил, банально не была прописана директория dynamic в named.conf
Процесс named сразу пропал из топа, проц перестал показывать загрузку вообще

Обновить с помощью yum update bind не получилось, у меня походу стоит самый последний (так как вчера делал полный yum update)

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

Feb 22 13:26:13 lcwmlw1126 named[3383]: client 127.0.0.1#33880 (140.103.30.218.in-addr.arpa): view external: query (cache) '140.103.30.218.in-addr.arpa/PTR/IN' denied

не знаю в какую сторону копать (

Bond James писал:

Ошибки исправил, банально не была прописана директория dynamic в named.conf Процесс named сразу пропал из топа, проц перестал показывать загрузку вообще

ЛА понизился, или остался по прежнему большой?
кстати, что в resolv.conf ?

На момент написания того сообщения LA был в норме (максимум 0,3) около 30 минут
Но стоило мне отлучиться на часа 1,5 - LA сразу подскочил до 1 в среднем

ps aux не показывает ничего подозрительного

в resolv.conf:

domain amhost.net
nameserver 85.17.150.123
nameserver 127.0.0.1
nameserver 127.0.0.1

я использую НСы на стороне регистратора (A запись)

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

Дартаньян писал:

AWD: мемекешь тебе не нравиться ишь какой.

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

JM писал:

Да к сожалению не всегда это происходит а иммено если идет обновление статсов...

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

Короче, проблема решилась.
Вчера очередной раз глянул top, LA опять была в среднем 1,3
Установил eAccelerator. Я даже не думал что эфект может быть такой впечатляющий - LA после этого упадо до 0, а сегодня утром были вот такие значения
load average: 0.01, 0.06, 0.04

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

Bond James: если что пробуй xcache

Bond James писал:

Установил eAccelerator. Я даже не думал что эфект может быть такой впечатляющий - LA после этого упадо до 0

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

Вообщем нифига не получилось (
eAccelerator установил, но в php.ini прописал не то что надо и поэтому сервер вообще не работал (оттуда и нули в LA)

Сейчас прописал то что нужно, сервер заработал, eAccelerator тоже
Ну и LA соответственно вернулась на уровень 1 в среднем, а в пике до 2 поднимается

Отключил httpd - LA не менялась

Отключил кроны - LA приняла значения 0.10, 0.09, 0.08

Так что получается дело именно в кронах

Странно что на Centos 5.X все работало нормально

Bond James: ты уверен что дело не в версии php, а как часто сейвит у тебя Mysql БД на диск?

Дартаньян писал:

Bond James: ты уверен что дело не в версии php, а как часто сейвит у тебя Mysql БД на диск?

а где это можно глянуть?

Bond - была у мня похожая ситуация на новом сервере без трафа, поставил два десятка с лишним смартов, он нихуёво загрузился когда включил кроны.
Отключал кроны, ЛА падало до 0.

Насколько я помню, помог именно тюнинг мускуля. Пропиши там большие параметры и кэши для myisam, innodb
Хрен его знает чего так, но на том сервере сейчас больше смартов, и почти все с трафом, ЛА 0.3 среднее. А так до тюнинга зашкаливало. хз че так.

И еще, попробуй из файла убрать s во времени крона.
sleep 1s
может из-за этой буквы косяк.

Bond James: скинь сюда или в личку my.cnf

а не пробовал что-то вроде ab -n 1000 -c 1 хttp://мойсайт.ога/
или ab -n 10000 -c 10 хttp://мойсайт.ога/ - и погляди, как работает. может все таки ла - результат плохого статомера))) не нужен перфекционизм, по себе знаю...
а про мускуль я писал на первой стр. - "ему дали 70-75% памяти?" - там уже глядеть надо, но мне пох
всем цветного зрения, любви, счастья, бабосов шоб не ныть

Проблему наконец-то решил
Переустановил ось - поставил Centos 6.3 только 32 битный
Все стало летать (до этого морда сайта /только html/ грузилась 5-30 секунд), LA стала 0,07 в среднем

Вот такая странная фигня

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