Дедик и сиджи что делать?:) оперативка.

El Nino писал:

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

в принципе вот это и хотелось услышать.
то есть можно еще добавлять сиджи но надо оптимизировать кроны или разнести их по времени то есть подтюнить софт. и рано думать пока про второй сервак.
во в этом и есть резюме.

vlad3d писал:

в принципе вот это и хотелось услышать. то есть можно еще добавлять сиджи но надо оптимизировать кроны или разнести их по времени то есть подтюнить софт. и рано думать пока про второй сервак. во в этом и есть резюме.

В CRON нужно настроить джиттер - он разнесет по времени. А 6Mbit это вообще ничего - хватит 1Gb RAM/Pentium-4 2.4Ghz А у тебя же сервак явно помощнее будет.

vlad3d писал:

DELL R200 Quad Core Xeon X3220 / 4GB / 2 x 160GB SATA (RAID1) в общем вот сервак какой стоит.

При правильном тюнинге такой сервер потянет на CJ 50Mbit

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 - самое время )

php под multithreaded апач надо пересобирать с флагом --enable-maintainer-zts, и отключать все подозрительные екстенжены. Я могу поручиться только за mysql и оракловский интерфейс. GD и Curl, скорее всего, не thread safe. Если кто броду не знает, то тогда остается другой вариант - fastcgi.

Dr.Syshalt:, подскажи вот что
на Линукс системах какие параметры sysctl подкручиваешь до каких пределов?

Mike Fox писал:

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

А можно пару конкретных советов по тюнингу мускуля?

Dr.Syshalt писал:

Если кто броду не знает, то тогда остается другой вариант - fastcgi.

А что именно из того что работает под Апачем - не будет работать под fastcgi? У меня сейчас стоит связка
nginx+Апач2 - сервер нагруженный Апач много памяти кушает - думаю про nginx+fastcgi. Какие бока в этой связке?

Я боков не встречал с этой связкой, все очень шустро и хорошо работает, сплошные плюсы на мой взгляд.
По поводу оптимизации MySQL, тут нужно не сервер оптимизировать, а структуры БД и запросы, это даст прирост в производительности в разы, а иногда и на порядки.

iRoot писал:

тут нужно не сервер оптимизировать, а структуры БД и запросы, это даст прирост в производительности в разы, а иногда и на порядки.

Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.

iRoot писал:

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

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

dlk44 писал:

.htaccess, PHP, Perl, CGI, XML, GeoIP, ssi, ImageMagick, GD, Zend Optimizer, ionCube и все прочее под этой связкой работает?

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

Цитата:

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

а какой смысл в этой связке? nginx сам по себе вебсервер, зачем ему апач )

может и боян но тема топика напомнила:

Цитата:

Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.

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

Цитата:

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

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

dlk44 писал:

А что именно из того что работает под Апачем - не будет работать под fastcgi?

Вот же неуч! "апач" и "fastcgi" - это не нечто, что противоречит друг другу. Под апачем можно так же точно запускать fastcgi процессы, для этого аж два модуля есть - mod_fastcgi и mod_fcgi. php под апачем можно запускать несколькими способами. mod_php, mod_suphp, два, что я упомнил с fastcgi, просто как cgi и еще есть парочка специальных.

PistoGanza писал:

Зато в большинстве случаев оптимизировать запросы на порядок сложнее и дороже чем взять вдвое более мощный процессор на +30 баксов.

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

color писал:

а какой смысл в этой связке? nginx сам по себе вебсервер, зачем ему апач )

Nginx отдает статику, а Апач PHP/CGI. Смысл в увеличении скорости и экономии памяти.

dlk44 писал:

Nginx отдает статику, а Апач PHP/CGI. Смысл в увеличении скорости и экономии памяти.

nginx и сам прекрасно отдает php через php-fastcgi (а еще лучше php-fpm), никакой экономии и скорости от появления здесь апача нет, только наоборот.

Dr.Syshalt писал:

Вот же неуч! "апач" и "fastcgi" - это не нечто, что противоречит друг другу. Под апачем можно так же точно запускать fastcgi процессы, для этого аж два модуля есть - mod_fastcgi и mod_fcgi. php под апачем можно запускать несколькими способами. mod_php, mod_suphp, два, что я упомнил с fastcgi, просто как cgi и еще есть парочка специальных.

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

И никто не говорил про противоречие - говорим про то что лучше и быстрее - связка nginx+Апач или связка nginx+fastcgi

color писал:

nginx и сам прекрасно отдает php через php-fastcgi (а еще лучше php-fpm), никакой экономии и скорости от появления здесь апача нет, только наоборот.

А пож php-fustcgi и php-fpm - все CJ скрипты работают?

а с чего им не работать? )

ну под suPHP половина скриптов НЕ работала - вот я и спрашиваю...

права неправильно значит настроили. больше не работать им там вроде не с чего.

dlk44 писал:

ну под suPHP половина скриптов НЕ работала - вот я и спрашиваю...

Кто то упоминал про CJ написанные на С ... это случайно не perlcc

deSilva писал:

Главное, чтобы не свопилось и ЛА не рос.

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