Как определить железо которое требуется серверу
 

Решили мы вот купить себе третий сервер.
Так как первый( он же вэб ) уже малек устарел(он одноядерный!) да и место на нем кончается.
Думаем вэб переташить на второй сервер( куплен с полгода назад ) Интел дуо, 4 гига рама и все такое.
Но опять же это не сервер - это комп в мелком корпусе( если смотреть комплектуюшие)

Есть идея что хватит мелочиться и купить нормальный сервер, типа хп или ВОТ ТАКОГО
И на нем базу поднять. Так как она по сути - самая тормознутая часть.

Все вот думаю - какую нагрузку он выдержит. И куда лучше копать..

купи нормальный U2 с расчётом на апгрейд и всё

на мой взгляд - лучше несколько дешевых купить и распределить проекты по ним - это будет дешевле и производительнее :)

четырёхядерные Xeon'ы как бы не хвалили но банальный ТОПовый двухядерник C2D по проивзодительности выше, причем в тех самых нужных местах MySQL, GD2, gzip и т.п. :)

лучше поставить ОЗУ побольше, ну и разумеется 64-битную ОСь, а то больше 4Гб корректно не заюзать :)

Все зависит от цели сервера.
Если с большими хардами - то райд массив с двухядерным процом
Если 50 простых сайтов - то любой сервак и хороший админ сервера.
Мало инфо, для чего третий сервер.

Третий сервер - в замену второго. Второй - в замену первого. Первый.. ну или хлам на него повесить, или пускай дампы хранит.
Сейчас второй сервер(БД) пеньДуо,4 гига, (загрузка 20%, 400 метров фри)
Первый - пеньСоло:) 2 гига(загрузка 8% и 200 метров фри)

Сейчас на железе крутиться три сайта на 30к униников в день в сумме.
Число постоянно растет, гдето на 5-10% в месяц.
Скоро планируется запуск еще одного сайта, лично на который у меня самые большие надежды.
Задача сервера - обеспечить все это быстрой базой данных.
Сейчас если все запустить на p43гц 2г рама то получаем от базы отказ в обслуживании( колво висяших конектов более 500)
В системе двух серверов работает нормально.
По данным логов(scanlog.ru(его время работы 1% от всего)) нагрузка на выдачу составляет 80%.
Есть за 24 часа 19 часов было потрачено на генерацию кода.
Время базы данных - 70% этого времени.

Я сталкивался с такой ситуацией, когда основной сайт был один большой тормоз. Убедился, что металл ни причем. У меня слабенький сервак (первый) с один камушкем, 4 рама, три харда по 500 гб. 18 сайтов в среднем по 30 уников. 3 сайта по 600. Один сайт большой 15 000 чел/сутки с стр 13,5.
Хороший спец все настроил так, что тьфу тьфу тьфу - тормоза никакого.

Настроил кого?
Вэб часть?
Она, извините не настраивается. Так разных хитрые плаваюшие кеши и другие фейки да враперы..

БД? У меня основная проблема в том что канал между серверами - 100Мегабит( вот такая вот сетевуха на старом сервере) и данные просто долго летают. Хотя конечно запросам типа MATCH или like '%' по 100к записям на эту задержку на*****ть абсолютно.
Где сейчас главная, корневая проблема - если возникает ЛЮБАЯ задержка с БД - тутже засирается очередь задач( ну скажем так 100 запросов в процес листе), частью таблицы лочаться. Частью ложиться канал(100Мб всеже).. И сиди кури бабмук, иногда снимай особо подвисшие запросики..
Минут через 5 очередь разгребается и потом ОЧЕНЬ сложно "подловить" более ну трех запросов в один момент..

Странно, могу сказать что сервер тип вашего хорошо держит порядка 60-80К уников, еще резерва есть чутка. Имеем на нем проекты довольно тяжелые, Интернет магазин с большой нагрузкой, замучено так что MySQL помимо юзерской части еще и 1С обслуживает, ну там dbf-ки туда сюда почти без перерыва, в общем винигрет настоящий. А второй проект крупный софтовый портал. И еще с десяток мелких.
Может вам стоит подумать не о железе, а об оптимизации кода, наверняка что-то перемудрили. И про memcached я вам уже расказывал (правда грубы вы были помню), тоже попробуйте не пожалеете, тем более что он по мускуль в основном и расчитан. И конечно же статику кидайте через гинкса.

Если же все такие решите брать железку, я бы посоветовал смотреть в сторону intel Core 2 Quad гигов 8 (минимум) оперативы, из ос бздю-64
Или прямо такую Hyperion

Удачи!

А вы случайно не pconect юзаете
Очень знакомую проблему описываете, когда запросы встают в очередь и дальше падают в sleep

Ну и плюс недавно у нас было хорошее такое падение БД.
InnoDB упали, и отказались напрочь свои бинлоги признавать обратно.
Пришлось постыдно откатываться на последние дампы кого чего где было.
Начальство было радо досмерти. Вот и хотелось бы фигнюшку чтобы не ломалась. А если ломалась чтобы чинилась быстро.
Сейчас базу с дампов залить.. Ну почти час что :(