Стандарты по нагрузке дедика под сиджы.

Я последние 2 месяца имею проблемы с перегруженностью серверов, причем внешне все вроде работает, но периодически падает прода на сайтах, где она долго имела устоявшиеся значения. После переноса части доменов с одного из дедиков, сразу заметно стало учучшение. В связи с этим хотелось бы узнать есть ли какие-то четкие общепринятые критерии по нагрузке дедиков, при которых можно быть увереным что все отдается юзерам быстро и плюс есть еще запас для роста траффа ?
У меня в статистике МРТГ доступны следующие показатели

1. Traffic Usage
2. Number of connections in ESTABLISHED/SYN_SENT state
3. Number of connections in TIME_WAIT/CLOSE_WAIT state
4. Load Average integer values
5. CPU Load
6. Memory Usage
7. MD0 Disk Usage
8. DISK IO /dev/sda
9. HTTPD2 workers
10. HTTPD2/FastCGId Process Count
11. APACHE cpu / memory usage
12. NGINX connections
13. NGINX cpu / memory usage
14. MYSQL queries count
15. MYSQL cpu / memory usage


Экспериментально понял что при средней загрузке проца 5. CPU Load 75% и выше могут начинаться проблемы с продой, при 50% все стабильно. Причем одно время работал сервер при загрузке проца под 100% и проблем не было, то есть однозначной зависимости нет.
Странно мне что 11. APACHE cpu / memory usage у меня например на одном из серверов 132%, то есть больше 100% !
Хотелось бы обсудить этот вопрос, буду благодарен за любые комментарии по делу.

Что за железо на сервере, какой дц?
Приаттачь месячные графики, хоть подрочим.

Имхо надо щепетильного админа нанимать, чтобы залез во все дыры сервера, поделал тесты и смотрел всякие лимиты.

Сервер
Server: HP DL 180G6
CPU: 2x Intel Quad Core E5504
RAM:24GB
Harddisks:4x300GB SAS - 15k

ДЦ - Амстердам, Лизвеб, сервер на 100 Мбит порту не shared.
Графики какие конкретно нужны, их там 15 штук, может проще даже дать доступ в МРТГ в привате

TGPtraffic_biz_inSect писал:

4. Load Average integer values

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

Цитата:

Экспериментально понял что при средней загрузке проца 5. CPU Load 75% и выше могут начинаться проблемы с продой, при 50% все стабильно. Причем одно время работал сервер при загрузке проца под 100% и проблем не было, то есть однозначной зависимости нет.

Потому что там еще приоритет задач влияет. Если там под nice что-то работает интенсивно (сбор статистик, например), то загрузка CPU может быть и высокой, но работать будет все равно все нормально.

Вообще самый лучший способ - померять производительность, а не гадать, глядя на народное творчество MRTG. Набери в гугле "site performance monitoring" и выбирай сервис.

на восьмиядернике - la 8 - нормально явление . 99% источник траблов - все уперлость в скорость веников . вынеси хотя бы мускул на ссд диск - усе залетает, гарантирую. сколько трафа дейли на этом серваке щаз и сколь стримротаторов?

Diablo II писал:

на восьмиядернике - la 8 - нормально явление .

А, точно, их там два четырехголовых, проглядел

Цитата:

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

Ну, я бы для начала все-таки в show processlist мускуля бы посмотрел, есть ли там куча запросов висячих, и если есть - то каких.

Траффа-то немного, 50-70 Мбит в пике, хотя сервер держал спокойно и 120. А хостеры мои говорят с одним крупным тубом такой сервак держит все 300 Мбит в пике.
А вот стримов дохрена, сейчас 51 насчитал, из которых штук 35 - откровенная мелочь по 1-5к. Я уже взял под такие мелкие сайты отдельный дедик и сгружу все туда, оставлю сайтов 15-20 основных. Если есть время и желание глянуть и помочь добрым советом, могу в приват скинуть доступы любые. Само собой с меня причитаться будет )
P.S. Не взыщите за ламерский вопрос, но что такое ССД-диск ? Тип винта или какой-то виртуальный диск ? Я знаю что вроде SAS-винты самые быстрые, они у меня и стоят. И хостеры мои держат свои сиджетубы крупные на таких же дедиках, правда делят статику и динамику по серверам. А у меня на данный момент для основных сиджетубов поделено тоже, а мелочь вся обычно отдается.

Вообще странно что на таком мощном сервере да и с таким мелким трафиком 50-70Мбпс да и то в пике есть проблемы. Такой сервер прокачать более 200-300Мбпс вполне реально. Явно как то криво все настроено.

Вот у тебя 4 харда, а они собраны как? Хорошо бы все 4 в зеркальном рейде и чтобы отдача была по очереди с каждого. Этого вполне хватит кушать более 100Мбпс, и ни какие ССД харды тут не нужны.

Оптимизируй все кроны от всяких стримов и прочих скриптов, сделай плавную обработку их в течении 1-2 мин. Так не будет пиков загруженности процессоров.

Ну а front-end NGNIX/back-end apach я так понимаю уже собран?

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

да уж , 50-70 мегабит вообще ни о чем же .
Dual Xeon E5520 2.27GHz Quad Core Nehalem
12GB рамы
HDD: 2x500GB+32GB Intel SLC SSD



на смартсидже все

systat -vmstat глянь в шелле

кроны у тебя в отдельный файлик вынесены? не в одно и то же время все 51 штук запускаются?
вот тут глянь по кронам: http://smartcj.com/wiki/doku.php?id=ru:cron_crontab_settings - для стрима так же сделай

ну и нгинкс + апач само-собой ,
чтоб с апача только скрипты отдавались - никакой статики

TGPtraffic_biz_inSect писал:

P.S. Не взыщите за ламерский вопрос, но что такое ССД-диск ? Тип винта или какой-то виртуальный диск ? Я знаю что вроде SAS-винты самые быстрые, они у меня и стоят.

SSD - Solid State Drive. Фактически - быстрая флэшка с SATA интерфейсом. На них случайные выборки идут быстро.

Надо смотреть, я думаю, iostat на дисках, поскольку их конфигурация не ясна, RAID там есть или нет, и если есть, то как. А то может оказаться, что вся нагрузка идет на один-два диска, остальные простаивают. Если ее по 4 разбросать равномерно, то тогда будет значительно быстрее.

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

Последний раз редактировалось: Dr.Syshalt (15/11/10 в 17:54), всего редактировалось 1 раз

Diablo II: В стриме есть настройки stream_max_crons, stream_max_grabs - может достаточно их покрутить ? Или именно лучше сделать как ты сказал ? У тебя самого сайты на стримах ?
Остальные скрипты - кристалы.

а какие скрипты то пользуешь?

1. Сколько баз на сервере?
2. Какой общий объем баз?
3. Какой тип баз используется? (Если InnoDB, то надо проверять настройки)
4. Сколько примерно активных файлов (так скажем количество тумб на морде * количество сайтов)?

Вот результаты TOP и systat -vmstat




top - 15:35:53 up 10:18, 3 users, load average: 10.86, 10.82, 9.18
Tasks: 205 total, 2 running, 203 sleeping, 0 stopped, 0 zombie
Cpu(s): 40.4%us, 7.9%sy, 0.0%ni, 46.7%id, 2.0%wa, 0.3%hi, 2.8%si, 0.0%st
Mem: 24676772k total, 20576992k used, 4099780k free, 1476744k buffers
Swap: 2321384k total, 0k used, 2321384k free, 13582884k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2918 mysql 15 0 4003m 2.1g 4004 S 96.0 8.8 576:44.57 mysqld
5774 apache 18 0 1890m 343m 5360 S 86.4 1.4 3:53.62 httpd2
7949 apache 13 -2 36188 16m 760 S 5.8 0.1 13:45.45 nginx
12698 1030 16 0 168m 12m 4284 S 5.8 0.1 0:06.40 php-cgi
1974 1002 15 0 168m 12m 4252 S 1.9 0.1 0:02.32 php-cgi
8905 classicp 15 0 169m 13m 4212 S 1.9 0.1 0:02.01 php-cgi
12560 apache 21 0 137m 12m 792 R 1.9 0.1 0:17.10 httpd2
1 root 15 0 10348 708 592 S 0.0 0.0 0:00.80 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.17 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1
6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/2
9 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2
10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
11 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/3
12 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3
13 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/3
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.09 events/0
15 root 10 -5 0 0 0 S 0.0 0.0 0:00.08 events/1
16 root 10 -5 0 0 0 S 0.0 0.0 0:00.08 events/2
17 root 10 -5 0 0 0 S 0.0 0.0 0:00.10 events/3
18 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
219 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
226 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
227 root 10 -5 0 0 0 S 0.0 0.0 0:00.57 kblockd/1
228 root 10 -5 0 0 0 S 0.0 0.0 0:00.27 kblockd/2
229 root 10 -5 0 0 0 S 0.0 0.0 0:00.32 kblockd/3
230 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
383 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
384 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/1
385 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/2
386 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/3
389 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
391 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
482 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
483 root 15 0 0 0 0 S 0.0 0.0 0:34.19 pdflush
484 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 kswapd0
485 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
486 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 aio/1
487 root 17 -5 0 0 0 S 0.0 0.0 0:00.00 aio/2
488 root 16 -5 0 0 0 S 0.0 0.0 0:00.00 aio/3
643 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
689 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 cciss_scan00
700 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
701 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 ata/1
702 root 14 -5 0 0 0 S 0.0 0.0 0:00.00 ata/2
703 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ata/3


vmstat:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 4079024 1478192 13606152 0 0 80 687 200 254 40 11 47 2 0

Последний раз редактировалось: TGPtraffic_biz_inSect (16/11/10 в 02:19), всего редактировалось 1 раз

Да, mysql - узкое место в системе.
Там либо запросы кривые к ней идут, либо сам mysql неоптимизирован.

Да и апач жрет процессор неслабо. Надо смотреть, чем он там таким напрягся, не похоже, что php - тот отдельными процессами, вроде.

Кстати, к тому, как работает php, есть вопросы. Оно не под suphp работает? А то вон я вижу процессы под разными юзерами. Если так - то suphp известный тормоз.

Винты в зеркальном рейде, админы говорят выносить мускул на ССД-диск смысла нет. Для начала попробую сделать 2 файла - файл с кронами стримов и файл с кронами трейдскриптов всех.А там посмотрим.

Diablo II писал:

на восьмиядернике - la 8 - нормально явление

Строго говоря, это не так.

Diablo II писал:

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

Без данных iostat по нагрузке на винтах, без размера таблиц и настроек mysql - что пальцем в небо.

Код:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2918 mysql 15 0 4003m 2.1g 4004 S 96.0 8.8 576:44.57 mysqld

96%cpu на mysqld это проблема. Либо mysql не достаточно настроен, либо программисты софта криворукие, возможно и то и другое.

Общался с админами, говорят все беды из-за мускуля.
Посмотрел сам phpmyadmin - есть базы до 1 ГБ размером, 6.000.000 записей. Таких больших баз не больше 10, еще ряд мелких. Также есть неиспользуемые базы - они могут как-то мешать ?
Вообще какие основные рекомендации по оптимизации mysql ?
И еще такой вопрос, может кому-то наивным покажется, но есть что-то такое ( записи мускуля, файлы ) что может со временем накапливаться и тормозить сервер все больше ? Просто мне странно что раньше держали сервера по 120 Мбит и было на них по 50-60 сайтов, а тепрь и на 40-50 Мбит уже тормозят.

TGPtraffic_biz_inSect писал:

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

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

Цитата:

Также есть неиспользуемые базы - они могут как-то мешать ?

Нет.

Цитата:

Вообще какие основные рекомендации по оптимизации mysql ?

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

Цитата:

И еще такой вопрос, может кому-то наивным покажется, но есть что-то такое ( записи мускуля, файлы ) что может со временем накапливаться и тормозить сервер все больше ?

Ну, очевидно - данные могут накапливаться. Вопрос - что? Будет интересно, если это какой-нибудь лог сообщений-ошибок, или что-то в этом духе... Если нет - попробуй optimize table прогнать на больших таблицах, порой помогает (на какое-то время).

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

Slow query log можно включить на mysql - он покажет, если какие-то запросы надолго зависают в обработке.

Ну и на апач, на самом деле, тоже надо смотреть, с какого хера http-сервер столько процессора жрет. Часто такое бывает из-за большого количества .htaccess с кучей rewrite-рулезов - он же их на каждом запросе ищет по всему дереву каталогов, потом парсит и тп. Отчасти может помочь внесение этих же рулезов прямо в конфиги апача и изменение AllowOverride на None - это отключает обработку .htaccess и апач их грузит один раз, на старте сервера.

ВОт кстати к вопросу об апаче, сейчас смотрю на самый проблемный сервак и вижу :
LA 18
А в таблице процессов
вижу апач и мускуль до 200 с лишним процентов доходит, там несколько апачей, это тот, у которого справа в таьлице COMMAND написано httpd2. Это при том что в верхней таблице CPU выше 88% не вылезает.
Как это понимать ?

Кстати .htaccess c реврайтами у меня используется на каждом сиджетубе, так галерная система работает.

Во первых поставь фронтендом нгинкс, перепиши реврайты под него, удали .htaccess'ы - это снимет большую нагрузку с апача, ну и смотреть запросы мускуля, избавлятся от 100500 галь в ротаторе. бо не раз видел что их и под 300к там висит непонятно за каким хуем.