forum.opennet.ru - "Организация высокогонагруженного сервера" (4)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Организация высокогонагруженного сервера"

Форумы 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ообщить модератору

Оглавление

Организация высокогонагруженного сервера, Michael, 10:22 , 20-Апр-10, (1)
Организация высокогонагруженного сервера, sHaggY_caT, 04:01 , 01-Май-10, (2)

Организация высокогонагруженного сервера, rusdis, 16:30 , 01-Май-10, (3)

Организация высокогонагруженного сервера, sHaggY_caT, 17:30 , 01-Май-10, (4)

Сообщения по теме [Сортировка по времени | 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 (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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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 (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ообщить модератору