По результатам проверки сервера на терпимость к нагрузкам поставлен следующий диагноз - будет жить, прихрамывая, пока в скорости не умрёт. Как вы, наверное, заметили, сервер в последнее время серьёзно сбоил - предпринимались различные попытки к повышениею его жизненного тонуса. Итого - без особых успехов. Это значит, что работать будет, но никакого "запаса" в мощности нет, потому при любой критической нагрузке начинаются проблемы (от слишком активной аудитории, выросшей в несколько раз за последний год и наплыва поисковиков до проблем при внутреннем обустройстве на сайте). Потому, с прицелом на совсем близкое будущее уже сейчас стоит задача - в течение месяца переехать на новый сервер.
На мой взгляд, главным тормозом видится подсистема памяти (но не объём, а скорость), т.к. используемый на сайте движок крайне активно работает с нею. Ухищрения с различными оптимизациями, ускорителями лишь смягчают, но не снимают проблемы, а часто - лишь добавляют глюков.
==========
Обновлено:
WebMoney:
Z764692734990
R326519264776
B425987194764
E713581971474
U347927897395
Яндекс.Деньги:
41001113406364
Украина:
ПриватБанк: Карточный счет Maestro 6762 4620 3472 0539 на имя Бакум Владимир
Беларусь (у кого нет Webmoney/Я-Денег).
Можно перевести жертвуемую сумму на счёт мобильного телефона:
МТС, 8652934, Севко Н.В.
Желательно два CPU по два ядра. Итого четыре. Или как вариант с одним CPU, но с двумя ядрами.
Процессоры AMD лучше по архитектуре, холоднее, работают на меньших частотах чем Intel. По цене они более приемлемые. Да и рынок серверов в последнее время серъезно сдвинулся в сторону AMD.
Этот конфиг более дорогой, но он мне лично больше нравится, чем Тиан.
Партизан подпольной луны aka (R)soft
>>> R-контроллер для Танка вполне возможно, что может быть реализован дополнительно.
Господа, забудьте об аппаратных контроллерах. Достаточно толкового чипсета с NCQ и совместимых дисков. Нам просто не нужна высокая производительность дисковой подсистемы. Усточивость ОC отлично обеспечивается софтовым зеркалом. Надежность хранения - бэкапами, что намного лучше чем RAID хотя и менее опративно в плане восстановления. Просто выбросьте этот пункт из списка критериев.
>>> Определить, что критично ?HDD?
Я неоднократно писал - критична производительность связки процессор/память. Если хотите что-то спросить дополнительно либо посоветовать - то пишите мне лично.
>>> Тогда от него и плясать.Если приспичило,то не коммерческая организация не деньги тратит, а берет "старое" железо-тут "старый" сервер у кого либо из обновивших свой IT предприятий.
Сейчас используется IBM eserver xSeries 330 867441X - 2xPIII-S 1.4Ghz, 1.75Gb REG ECC SDRAM PC133, 2x146Gb SCSI 10kRPM. Нужна система которая превосходит данную в части производительности CPU/RAM, т.к. именно этого ресурса не хватает и это вызывает тормоза.
При прочих равных - я наверное все-таки за Tyan, если варианты только такие...
Мой вариант - наверное не самый лучший
http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF06a/382783-383839-386059-386059-12083171-12567058.html
По крайней мере с ОС порблем быть не должно.
>>> Полностью солидарен с Богданом - надо смотреть в чем источники нынешних проблем. С дуру можно и годаздо более крутой сервер довести до состояния нестояния (проверено на практике). По-этому предлагаю все-таки "напрячь" Llama или DanZer-а на предмет профилирования под нагрузкой с орг-выводами (т.е. попытаться оптимизировать наиболее жручие участки кода).
То что сейчас сделано на сервере позволяет мне однозначно утверждать что процессор пожирается drupal'ом - в большей степени php, в меньшей степени БД.
Профилировать php под нагрузкой особо нечем по-моему, но поиски не закончены. Кстати, Danzer'а что-то давненько не видно.... В принципе, если найдется профайлер толковый - я возмусь его поставить на время, но интерпретировать его показания я врядли толком смогу. Проблема в том, что фиксить код и запросы к БД просто-напросто некому. Ну нету тут php-программистов пока
ex-K9
На работе приходилось запускать PHP с профилятором. В результате переписав пару-тройку неоптимальных фрагментов кода производительность на том же железе подняли в разы, а выкинув динамическое формирование части контента (теперь он генерится не для каждого зашедшего посетителя а после каждого влияющего на него изменения и сливается в статический файл) суммарное улучшение производительности выросло на порядок, в результате чего узким местом при пиковых звагрузках стала Циска, которой оказалось не по силам прокачивать сквозь себя гигобайты компрессированного трафика в час. Если получится, постараюсь на днях пообщаться с коллегами, которые занимались этим непосредственно.
За несоответствие действительности Вашим о ней представлениям администрация форума ответственности не несет.
Xeon UP? Уже ограничиваемся. Вероятность поддержки Йорков минимальна. Я против платформы LGA771, точнее чипсетов i5000X\5400 и более старых. Если только на P35\X38\975X, что малореально. Чипсеты серверные у Интел ущербны сами по себе ввиду архитектуры и сливаю AMD иногда вдвое. thg.ru/cpu/intel_xeon_woodcrest_amd_opteron/index.html
Смотрим скорость памяти.
Про оптимизацию я согласен. Я за Tyan, тем более, что DDR2 холоднее и можно воткнуть в перспективе четырёхъядерные процессоры.
Вместе мы - www.ROM.by!
Я мало понимаю в серверном железе и ничего не знаю о друпале, кроме того что он есть
Но у меня складывается впечатление, что мы пытаемся увезти воз картошки на Феррари.
Мы задавим существующую проблему мощью нового железа, но у меня есть стойкое опасение, что проблем со временем прибавится. Может стоит последовать совету rgt и посмотреть пока в сторону оптимизации кода?
И не спрашивайте меня где нам взять друпальщика Я просто высказал свое мнение.
Jazz, Blues & Rock'n'Roll фарева!
Согласен, но предлагаю более комплексный подход - вообще сервак посмотреть на предмет грамотности настройки FreeBSD, движков разных, как грамотно их держать. Есть человек, занимающийся Фряхами, но не Друпалом
Но лучше что-то...
Вместе мы - www.ROM.by!
Уважаемые, друпал, его "оптимизация" и т.п. - ни при чём. Точней (и правильней) - не есть причина, а лишь её усугубление (дополнительная нагрузка на сервер). Потому и рассматривать его влияние нужно как следствие, а не причину. И лечить болезнь, а не её проявление.
В то же время, если кто-то найдёт продвинутых людей, кто сделает нужное для оптимизации (что сделать - я знаю, в своё время писал об этом пропавшему Danzer-у) - будет, естественно, неплохо. Однако есть ещё один аспект - можно предположить, что стоимость подобных услуг в конце концов даст лишь дополнительный довод в пользу решения всё той же упомянутой причины.
P.S. Прошу раз и навсегда прекратить безсмысленный флейм "Intel против AMD". Для того чтобы сделать глубокомысленные выводы нужно иметь два таких, да поюзать их конкретно. Вопрос в приложениях, а практического опыта и фид-бека мало у кого есть.
Открытая книга: icbook.com.ua
Согласен, интел, современный, хорошая число-дробилка. А вот если рассматривать скорость работы платформы в целом есть некоторые неприятные моменты.
Если у нас узкое место именно подсистема процессор-память, то надо смотреть в сторону дуальной(физически два сокета) платформы под OPTERON. Это дает четыре канала доступа к памяти(двухканальный контроллер в каждом из процев), плюс экстремально низкая, для интела вообще пока недостижимая, латентность при обращении к памяти.
Я когда впервые столкнулся с такой конфигурацией долго не мог понять, какого такого, в тестах на чтение из памяти оно показывает цифры выше теоретического придела для стоящей там DDRII 667.
ГГТ! (Граждане-Господа-Товарищи)
Давайте не будем обсуждать вкус, цвет и качество рамбутана и гуанабы по сравнению с личи и саподиллой. Не надо путать лунъянь с дурианом. Потому прошу разглагольствование в стиле
IvsAсчитать закрытым.На повестке дня видится серьёзным ограничение "БП потребленее > 300Ватт". Вопрос - какая "следующая планка" ограничения по питанию (450Вт? 600Вт?) и насколько сильно увиличивается в зависимости от этого расходы, чтобы рассматривать это как, собственно, ограничение?
Отправить комментарий