Master-X
Форум | Новости | Статьи
Главная » Форум » Хостинги / Домены / Железо » 
Тема: Дедик и сиджи что делать?:) оперативка.
цитата
20/06/09 в 00:57
 vlad3d
El Nino писал:

на 6 мбитах проблема надумана безусловно

в принципе вот это и хотелось услышать.
то есть можно еще добавлять сиджи но надо оптимизировать кроны или разнести их по времени то есть подтюнить софт. и рано думать пока про второй сервак.
во в этом и есть резюме.
цитата
20/06/09 в 02:50
 dlk44
vlad3d писал:
в принципе вот это и хотелось услышать.
то есть можно еще добавлять сиджи но надо оптимизировать кроны или разнести их по времени то есть подтюнить софт. и рано думать пока про второй сервак.
во в этом и есть резюме.


В CRON нужно настроить джиттер - он разнесет по времени. А 6Mbit это вообще ничего - хватит 1Gb RAM/Pentium-4 2.4Ghz А у тебя же сервак явно помощнее будет.
цитата
20/06/09 в 02:58
 dlk44
vlad3d писал:
DELL R200 Quad Core Xeon X3220 / 4GB / 2 x 160GB SATA (RAID1)
в общем вот сервак какой стоит.


При правильном тюнинге такой сервер потянет на CJ 50Mbit
цитата
20/06/09 в 13:02
 Dr.Syshalt
deSilva писал:
Про prefork ты прав, но не совсем. Он создает также пул запущеных, готовых к работе child-процессов, память между которыми шарится, и не сильно тратится во время ожидания. Да и память сейчас - не самый дорогой ресурс.
По скорости работы на сиджах скажу, что worker быстрее на 3-5% всего отрабатывал, и то не во всех случаях, но с ним часто бывают приколы, когда процесс залипает, и убить его нельзя, разве что ребутом машины.
Я думаю, что только поэтому большинство юзает апач1 или апач2(префорк).


Насчет "во время ожидания" - да. Но когда к твоему серверу идет две сотни запросов, они все обслуживаются двумя сотнями процессов. Шарится fork'ом только сегмент кода и - до записи в него - сегмент данных. Heap же не шарится. А heap в случае, если мы используем php, используется нещадно каждым процессом. Вот тут неприятности-то наши с префоркнутым апачем и начинаются :} То есть на каждый этот процесс php "засасывает" в него скрипт и все его инклуды, компилирует (ну, если там акселератор стоит, это не так долго уже - но память-то оно все равно ест!). 200 процессов, каждый из которых отожрет память под php, даже просто чтоб zend engine заработал - это уже немало совсем. Вот и пухнет апач под нагрузками, все закономерно. И насчет 3-5% - это опять-таки, закономерно - пока апач не начинает биться в своп. Вот когда, распухший, начинает - и возникают те самые "разницы в разы", которые народ отмечает с тем же nginx'ом. А так, в принципе, скорость, с которой отработает php-скрипт, уж точно не от веб-сервера зависит. А скорость выдачи статики больше, опять-таки, зависит от того, хуярит ли веб-сервер на каждый запрос по дереву директориев в поисках .htaccess, или нет.

По поводу залипания - так я о причине и написал в том самом абзаце, который ты отквотил:

Цитата:
В том числе со многими php extensions может быть проблем достаточно - в случае использования mod_php.


(если кому хочется устроить пятиминутку ненависти к php - самое время icon_smile.gif )

php под multithreaded апач надо пересобирать с флагом --enable-maintainer-zts, и отключать все подозрительные екстенжены. Я могу поручиться только за mysql и оракловский интерфейс. GD и Curl, скорее всего, не thread safe. Если кто броду не знает, то тогда остается другой вариант - fastcgi.
цитата
20/06/09 в 13:26
 El Nino
Dr.Syshalt:, подскажи вот что
на Линукс системах какие параметры sysctl подкручиваешь до каких пределов?
цитата
21/06/09 в 01:59
 dlk44
Mike Fox писал:
со стримами нужно обязательно тюнить мускуль, иначе это как на автобусе проехать квотер за 12 секунд. очень часто мускуль с дефолтными настройками упирается в диск и тп


А можно пару конкретных советов по тюнингу мускуля?
цитата
21/06/09 в 02:12
 dlk44
Dr.Syshalt писал:
Если кто броду не знает, то тогда остается другой вариант - fastcgi.


А что именно из того что работает под Апачем - не будет работать под fastcgi? У меня сейчас стоит связка
nginx+Апач2 - сервер нагруженный Апач много памяти кушает - думаю про nginx+fastcgi. Какие бока в этой связке?
цитата
21/06/09 в 09:18
 iRoot
Я боков не встречал с этой связкой, все очень шустро и хорошо работает, сплошные плюсы на мой взгляд.
По поводу оптимизации MySQL, тут нужно не сервер оптимизировать, а структуры БД и запросы, это даст прирост в производительности в разы, а иногда и на порядки.
цитата
21/06/09 в 15:21
 PistoGanza
iRoot писал:
тут нужно не сервер оптимизировать, а структуры БД и запросы, это даст прирост в производительности в разы, а иногда и на порядки.


Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.
цитата
21/06/09 в 18:43
 dlk44
iRoot писал:
Я боков не встречал с этой связкой, все очень шустро и хорошо работает, сплошные плюсы на мой взгляд.


.htaccess, PHP, Perl, CGI, XML, GeoIP, ssi, ImageMagick, GD, Zend Optimizer, ionCube и все прочее под этой связкой работает? И какие конкретно плюсы по сравнению со связкой nginx+Апач?
цитата
21/06/09 в 19:35
 color
dlk44 писал:
.htaccess, PHP, Perl, CGI, XML, GeoIP, ssi, ImageMagick, GD, Zend Optimizer, ionCube и все прочее под этой связкой работает?

все кроме htaccess. CGI "из коробки" тоже работать не будет, враппер писать надо. ImageMagick к веб-серверу никакого отношения не имеет.
Цитата:

И какие конкретно плюсы по сравнению со связкой nginx+Апач?

а какой смысл в этой связке? nginx сам по себе вебсервер, зачем ему апач )
цитата
22/06/09 в 00:39
 rst630
может и боян но тема топика напомнила:
цитата
22/06/09 в 07:50
 iRoot
Цитата:
Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.

Для небольших проектов это на первое время сгодится, но вертикально масштабировать сервер до бесконечности не получится, горизонтально будет не проще, чем прочитать и понять раздел "Optimizations" из доки по базе данных и запустить скрипт под профилировщиком чтобы найти узкие места.

Цитата:
И какие конкретно плюсы по сравнению со связкой nginx+Апач?

Менше памяти расходуется, FastCGI работает быстрее, чем проксирование (протокол легче), как по мне, то в настройке поддержке проще - уходит звено из связки, которое нужно обновлять, настраивать, доки читать.
цитата
22/06/09 в 14:11
 Dr.Syshalt
dlk44 писал:
А что именно из того что работает под Апачем - не будет работать под fastcgi?


Вот же неуч! "апач" и "fastcgi" - это не нечто, что противоречит друг другу. Под апачем можно так же точно запускать fastcgi процессы, для этого аж два модуля есть - mod_fastcgi и mod_fcgi. php под апачем можно запускать несколькими способами. mod_php, mod_suphp, два, что я упомнил с fastcgi, просто как cgi и еще есть парочка специальных.
цитата
22/06/09 в 14:30
 Dr.Syshalt
PistoGanza писал:
Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.


Да если бы все в проц упиралось только - это еще полбеды было бы, но неоптимальные запросы имеют тенденцию
1) Упираться в диск - а "вдвое более быстрый" винт получится совсем не +30 баксов.
2) становиться не вдвое тормознее при увеличении в два раза объема базы, а в квадрате вдвое. Ну тобишь вчетверо. Убить самую мощную машину херово написанными запросами - как два пальца обоссать. А многие пользуются базой как разновидностью текстовых файлов, "все равно машины сегодня быстрые", почему потом и могут возникнуть вопросы с производительностью каких-то несчастных 30 сиждей на охренеть, вообще-то, насколько мощной железке.
цитата
22/06/09 в 22:08
 dlk44
color писал:
а какой смысл в этой связке? nginx сам по себе вебсервер, зачем ему апач )


Nginx отдает статику, а Апач PHP/CGI. Смысл в увеличении скорости и экономии памяти.
цитата
22/06/09 в 22:13
 color
dlk44 писал:
Nginx отдает статику, а Апач PHP/CGI. Смысл в увеличении скорости и экономии памяти.

nginx и сам прекрасно отдает php через php-fastcgi (а еще лучше php-fpm), никакой экономии и скорости от появления здесь апача нет, только наоборот.
цитата
22/06/09 в 23:46
 dlk44
Dr.Syshalt писал:
Вот же неуч! "апач" и "fastcgi" - это не нечто, что противоречит друг другу. Под апачем можно так же точно запускать fastcgi процессы, для этого аж два модуля есть - mod_fastcgi и mod_fcgi. php под апачем можно запускать несколькими способами. mod_php, mod_suphp, два, что я упомнил с fastcgi, просто как cgi и еще есть парочка специальных.


У меня стоит mod_php потому что под ним нормально работают все CJ скрипты.

И никто не говорил про противоречие - говорим про то что лучше и быстрее - связка nginx+Апач или связка nginx+fastcgi
цитата
22/06/09 в 23:49
 dlk44
color писал:
nginx и сам прекрасно отдает php через php-fastcgi (а еще лучше php-fpm), никакой экономии и скорости от появления здесь апача нет, только наоборот.


А пож php-fustcgi и php-fpm - все CJ скрипты работают?
цитата
22/06/09 в 23:51
 color
а с чего им не работать? )
цитата
23/06/09 в 19:41
 dlk44


ну под suPHP половина скриптов НЕ работала - вот я и спрашиваю...
цитата
23/06/09 в 21:41
 color
права неправильно значит настроили. больше не работать им там вроде не с чего.
цитата
30/06/09 в 17:00
 nagual3
dlk44 писал:
ну под suPHP половина скриптов НЕ работала - вот я и спрашиваю...

Кто то упоминал про CJ написанные на С ... это случайно не perlcc smail101.gif
цитата
06/07/09 в 09:43
 dlk44
deSilva писал:
Главное, чтобы не свопилось и ЛА не рос.


По опыту могу сказать, что LA не такой уж и критический показатель - даже при 5 все нормально работает. А по поводу свопа - тут от его размера все зависит если не более 15% от объема RAM то современная ось нормально эффективно работает - конечно при условии что нет сильной нагрузки на тот жесткий дисе где этот самый своп находиться. К примеру я на своих серверах под CJ использую 2 hdd SATA - на первом диске ось, базы данных mySQL и своп. А на втором диске клиентские аккаунты (скрипты, картинки). Схему такого размещения придумал сам так как знаю как снижается скорость чтения с диска при одновременной записи - поэтому второй HDD используется преимущественно на чтение.
Стр. « первая   <  1, 2, 3


Эта страница в полной версии