The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Организация высокогонагруженного сервера"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы WEB технологии (Оптимизация, производительность)
Изначальное сообщение [ Отслеживать ]

"Организация высокогонагруженного сервера"  +/
Сообщение от mr.roter on 20-Апр-10, 00:00 
Приветствую всех!
Занимаюсь проектом с посещаемостью ~25k хостов в сутки.
Столкнулся с проблемой, что текущего железа, видимо, не хватает.
Сейчас стоит 8GB RAM + Intel Xeon E5410 2.33 ГГц.
Из ПО: FreeBSD 7.2, nginx, php-fpm, mysql5.

При генерации страниц при нагрузках наблюдаю следующая картину: запросы к БД занимают к примеру 300ms, а страница вся генерится 4-5sec.
Когда нагрузки толком нет (100-200 юзеров онлайн), то запросы к примеру занимают 100-150ms, а общее время генерации страницы 300-400ms.

Сначала оптимизировал запросы, таблички. Раньше в top на первом месте при нагрузках всегда висел mysqld, сейчас (после оптимизаций БД) mysqld далеко не на первом месте, а на первом месте и вообще в топе процессы php-fpm.

SHOW PROCESSLIST почти все время пустой, 1-2 запроса выполняются.

в top примерно следующая ситуация:
last pid: 87333;  load averages:  9.09,  9.54, 9.69                                
192 processes: 16 running, 174 sleeping, 2 stopped
CPU 0: 89.8% user,  0.0% nice, 10.2% system,  0.0% interrupt,  0.0% idle
CPU 1: 91.0% user,  0.0% nice,  5.6% system,  0.0% interrupt,  3.4% idle
CPU 2: 94.0% user,  0.0% nice,  4.9% system,  0.0% interrupt,  1.1% idle
CPU 3: 94.0% user,  0.0% nice,  3.4% system,  0.0% interrupt,  2.6% idle
Mem: 1053M Active, 5421M Inact, 740M Wired, 235M Cache, 399M Buf, 439M Free
Swap: 4096M Total, 528K Used, 4095M Free
Как я понимаю, все упирается в процессор.
1. Насколько сильно может помочь установка второго такого же процессора в сервер?

Вот еще статс nginx'а:
Active connections: 921
server accepts handled requests
15814759 15789148 154277883
Reading: 2 Writing: 60 Waiting: 859  


Собственно, собираюсь ставить второй сервер для некоторых других нужд и думаю разгрузить основной сервер, перенеся на второй всю статику.
2. Или может лучше на втором оставить php-fpm только, раз он столько потребляет?
3. Или может на него (второй сервер) лучше вынести mysql?
4. А может железо такого за глаза должно хватать для веб-портала средних размеров, просто код кривой?
5. Или может настройки ПО кривые какие-то?

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

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Организация высокогонагруженного сервера"  +/
Сообщение от Michael (??) on 20-Апр-10, 10:22 

>Как я понимаю, все упирается в процессор.

верно
>1. Насколько сильно может помочь установка второго такого же процессора в сервер?

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

прененос статики почти ничего вам не даст
>3. Или может на него (второй сервер) лучше вынести mysql?

а вот перенос базы на выделенный сервер - неплохая идея

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Организация высокогонагруженного сервера"  +/
Сообщение от sHaggY_caT (ok) on 01-Май-10, 04:01 
>[оверквотинг удален]
>
>При генерации страниц при нагрузках наблюдаю следующая картину: запросы к БД занимают
>к примеру 300ms, а страница вся генерится 4-5sec.
>Когда нагрузки толком нет (100-200 юзеров онлайн), то запросы к примеру занимают
>100-150ms, а общее время генерации страницы 300-400ms.
>
>Сначала оптимизировал запросы, таблички. Раньше в top на первом месте при нагрузках
>всегда висел mysqld, сейчас (после оптимизаций БД) mysqld далеко не на
>первом месте, а на первом месте и вообще в топе процессы
>php-fpm.

memcache?

>[оверквотинг удален]
>CPU 1: 91.0% user,  0.0% nice,  5.6% system,  0.0%
>interrupt,  3.4% idle
>CPU 2: 94.0% user,  0.0% nice,  4.9% system,  0.0%
>interrupt,  1.1% idle
>CPU 3: 94.0% user,  0.0% nice,  3.4% system,  0.0%
>interrupt,  2.6% idle
>Mem: 1053M Active, 5421M Inact, 740M Wired, 235M Cache, 399M Buf, 439M
>Free
>Swap: 4096M Total, 528K Used, 4095M Free
>Как я понимаю, все упирается в процессор.

Да, CPU

>1. Насколько сильно может помочь установка второго такого же процессора в сервер?

Может помочь :)

>[оверквотинг удален]
>
>
>Собственно, собираюсь ставить второй сервер для некоторых других нужд и думаю разгрузить
>основной сервер, перенеся на второй всю статику.
>2. Или может лучше на втором оставить php-fpm только, раз он столько
>потребляет?
>3. Или может на него (второй сервер) лучше вынести mysql?
>4. А может железо такого за глаза должно хватать для веб-портала средних
>размеров, просто код кривой?
>5. Или может настройки ПО кривые какие-то?

Вы не привели всех данных, я бы вообще хотела суточные профили по sar увидеть, что бы делать какие-то выводы.

Да и тот же gstat интересен... Вообще часто проекты таки сидят по диску из-за базы (но в Вашем top именно cpu)

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

Встает вопрос, как обеспечить актуальность контента? Есть несколько способов:

1. rsync, чревато тем, что "что-то где-то недосинкается"
2. SAN на все серверы, сколько бы их в дальнейшем не было (чревато большими тратами $)
3. кластерная фс/блочное устройство - чревато сменой FreeBSD на Linux и тормозами по i/o
4. Храним все в MySQL, серверы баз данных реплицируем с друг другом: чревато усложнением архитектуры и проблемами со статикой

Можно коомбинировать :)

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Организация высокогонагруженного сервера"  +/
Сообщение от rusdis email(ok) on 01-Май-10, 16:30 
>Кроме распределения нагрузки, есть еще вопрос стабильности: два сервера это менее надежно,
>чем один, а три.. ну.. Вы понимаете...

IMHO 2 сервера это надежнее чем 1, nginx позволяет балансировать нагрузку с указанием весов для каждого сервера, если БД нагрузки не дает, то можно просто часть трафика отправлять на другую машину, а БД использовать одну.

http://sysoev.ru/nginx/docs/http/ngx_http_upstream.html

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Организация высокогонагруженного сервера"  +/
Сообщение от sHaggY_caT (ok) on 01-Май-10, 17:30 
>>Кроме распределения нагрузки, есть еще вопрос стабильности: два сервера это менее надежно,
>>чем один, а три.. ну.. Вы понимаете...
>
>IMHO 2 сервера это надежнее чем 1, nginx позволяет балансировать нагрузку с
>указанием весов для каждого сервера, если БД нагрузки не дает, то
>можно просто часть трафика отправлять на другую машину, а БД использовать
>одну.
>
>http://sysoev.ru/nginx/docs/http/ngx_http_upstream.html

Я об этом написала :) надежнее, только если общий сторадж и/или настроена репликация

то есть, 2 x 2 x 2:

2 фронт-энда (Nginx, да, лучшее решение, но правильнее нагрузку на него самого балансить на уровне IP-протокола циской, или такими решениями как LVS)
2 бэкэнда (с общим стораджем идеально)
2 сервера БД с репликацией

Не путайте, пожалуйста, двухзвенную архитектуру, которая сама по себе по определению неустойчива, и HA-кластер.
Но жизнь хороша в том, что все решения можно коомбинировать :)

По факту может так же быть, с целью HA, а не снижения нагрузки:

1. Два сервера, на которых поднято вообще все, перед ними циска и/или lvs. Балансировка round-robin. Есть так же Carp, что бы подхватить IP грохнувшегося сервера, а еще bgp, для того, что бы все поднялось в территориально-удаленном ДЦ :)
2. Такая же двухзвенная или трехзвенная архитектура, но с дублированием всех или части звеньев на одном сервере (например, если цель HA, а не балансировка, можно повесить и резервную БД, и резервный бэкэнд на один сервер)

Но топикстартер спросил не об HA-кластере, а о балансировке нагрузки :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру