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 - самое время
)
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
цитата
06/07/09 в 09:43
dlk44
deSilva писал:
Главное, чтобы не свопилось и ЛА не рос.
По опыту могу сказать, что LA не такой уж и критический показатель - даже при 5 все нормально работает. А по поводу свопа - тут от его размера все зависит если не более 15% от объема RAM то современная ось нормально эффективно работает - конечно при условии что нет сильной нагрузки на тот жесткий дисе где этот самый своп находиться. К примеру я на своих серверах под CJ использую 2 hdd SATA - на первом диске ось, базы данных mySQL и своп. А на втором диске клиентские аккаунты (скрипты, картинки). Схему такого размещения придумал сам так как знаю как снижается скорость чтения с диска при одновременной записи - поэтому второй HDD используется преимущественно на чтение.
Стр.
« первая
<
1
,
2
,
3
Новая тема
Ответить
Эта страница в полной версии