unsorted ~ Новый сервер

Возраст: 45 C нами с 22.11.2005 Репутация: **109.8**

Рыся, zelen,
Всё верно. Только брать более простое решение на 3000 платформе не имеет никакого смысла, т.к. экономия мизерная получается. Лично я бы брал процы 5310, за них просят совсем смешные деньги. Дисковая в случае нехватки производительности (во что очень слабо верится) просто апгрейдится до 10 рейда.

Возраст: 41 C нами с 20.09.2004 Репутация: **177.5**

zelen, т.е. дисбаланс вам видится между вычислительной мощью и её использованием? Ну тогда выжение "несбалансированная конфигурация" некорректно, т.к. в саму кофигурацию никак не попадает то, для чего она будет использоваться.
Называйте уж вещи своими именами, давайте без ложной корректности. Так и скажите: "Зачем вам, парни, такой крутой сервак, если и на существующем ничего хорошего не можете сделать?".

Как уже не раз упоминалось в этой теме, было решено взять сервер с запасом, чтобы на 100% удовлетворить существующие потребности и оставить задел на будущее развитие проекта и возможно новые проекты. Ответил на вопрос?

Возраст: 57 C нами с 08.03.2005 Репутация: 95

Рыся писал(а):

Судя по статистике, которую я наблюдаю, узкое место —множественные SQL запросы

честно говоря, я это и подозревал, поэтому так удивился предложенной конфигурации.
Можно получить статистику:
запросов/сек,
средняя длинна запроса,
Процент использования индексов,
отношение запросов чтение/запись.
ну и что за база данных используется.

Возраст: 39 C нами с 30.09.2004 Репутация: **102.4**

zelen, просто смешное сообщение. какая разница какая длина у запроса? Что такое рпоцент использования индексов? Да и вообще как могут эти сведения комуто помочь.

Всем, Я вообще не специалист по производительности, да и не специалист вообще ни в чем. Но немного представляю, как работает phpbb.

А насчет дискового массива, о котором так все говорят. Да вся база у форума не больше 500 мегабайт (включая индексы), 200 из которых я думаю занимает поисковая таблица форума. Еще мегабайт 50 таблица с сообщениями форума, та которая с текстом (у phpbb она отдельная). Остальное еще 100 таблиц по 1 мегабайту каждая. Ну там может разьве что таблица с блогами и трекером со статистикой большие и т.п.

Так что гипотетический вся база может влезть в озу и вообще не важно какой диск используется. Потому что форум (php файлы) занимает еще +10 и свободно вмещается в дисковый кеш. HDD не нужен. На него будет только изредка (в компьютерных понятиях) сбрасываться результат работы mysql.

Вопрос: почему все не работало раньше и тормозило так сильно? Незнаю.

Я в свое время анализировал работу запросов, пытался найти узкие места. Брал просто тупо index.php и сверху вниз просматривал запросы все, засекал сколько выполняются.

Итог: найти просто так нахаляву "затык" и исправить его мне кажется маловероятным. Тормоза складываются по копеечкам. Отовсюду.

Спасения в статике не может быть, слишком много разграничений по правам. Да и вообще это слишком сложно.

Мое мнение: объемов для хранения информации хватало, не хватало вычислительной мощности, для выполнения сложных запросов. Много процессоров мощных - спасут.

Не факт, что я прав.

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

В целом согласен с iZz. Вся база данных + кэш диска для этого необходимый спокойно влезут в 4 GB. И диски тут особо не причем. Критична пропускная способность памяти и ресурсы процессора. В данный момент памяти на всех явно мало(3GB), что вызывает резкое увеличение времени процесса в режиме ядра за счет подкачки и частым обращениям к диску.
Если пихать весь сервер, то да - быстрые диски понадобятся. Картинки все ни в какую память не влезут. Да и апачу самому по себе памяти надо много...

Возраст: 39 C нами с 21.02.2005 Репутация: **132.4**

iZz, baldahin, а зачем вообще тогда жесткие диски навороченные? может купить побольше оперативки?

1) есть проги, которые позволяют использовать часть оперативки как обычный хдд, естественно проги серьезные, платные.

2) есть устройство
http://www.ixbt.com/storage/gigabyte-iram-p1.shtml
стоит 150 баксов + 4Гига(2гига) первой ддр - это около 280(140)
итого за 400(300) получаем штуку с гарантированной лин. скоростью 120 и временем выборки на два порядка меньше любых рейдов, ну и экстремально малым объемом конечно Смайлик

в принципе есть аналоги данного устройства, но не знаю есть ли они у нас в стране Смайлик

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

Suber, для этого не нужны проги:
а) линукс неплохо забивает всю свободную память кэшем диска
б) есть такое древнее понятие как ram disk.

C нами с 21.03.2005 Репутация: **130.5**

Собственно обзоры серверных платформ интела и амд на данный момент говорят, что первый выигрывает, да и надежность интела всегда была выше амд.
Tom's Hardware Guide

Возраст: 45 C нами с 22.11.2005 Репутация: **109.8**

Suber,
Эти диски (74GB 10K SCSI) стоят всего 150 уёв. Подмигивание

Куда дешевле то?
Делавар,
А нет ли случайно тестов 21ХХ оптеронов? Или там только сокет заменили?

C нами с 15.07.2005 Репутация: **133.9**

Делавар, имхо некорректное сравнение. Интересно, почему THG сравнивает Xeon 5160 с Opteron'ом 285, а не с более современным Opteron'ом 2220, который дешевле вышеупомянутого Xeon'a на $200 ?

Цитата:

да и надежность интела всегда была выше амд

А вот это уже флуд, батенька. Фу!

Возраст: 37 C нами с 03.04.2006 Репутация: **73.7**

Вот тут сравниваються как раз те самые Opteron 2220 и Xeon 5160. Можно заглянуть перед выбором. В принцепи как я понял большой разници нет, так что видимо выбор между Opteron и Xeon это дело вкуса...

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

DStar17, тоже всегда такие тесты убивали... Хотя топовые модели интел явно быстрее, в нижнем секторе это еще большой вопрос. В оптеронах мне нравится модель памяти. И общая скорость (а с NUMA и подавно) и латентность смотрятся лучше,а это один из основных критериев.

Возраст: 57 C нами с 08.03.2005 Репутация: 95

baldahin
Произведём небольшое лирическое отступление.
Сравним 3 жестких диска: современные - ST373455LC,ST3400832NS и 7 летней давности - ST318452LW
ST373455LC ST318452LW - 15 тысячники так сказать enterprise-серия.
ST3400832NS - обычный SATA
Вот их параметры:

                                                        ST373455LC  ST318452LW ST3400832NS
устоявшаяся скорость чтения данных:    96 Мб/с    47 Мб/с      55 Мб/с
Среднее время доступа, чтение:           3.5 мс       3.9 мс         8 мс
Среднее время доступа, запись:              4 мс       4.2 мс         9 мс
Время доступа full stroke:                    6.7 мс       7.9 мс       нет данных 
Время доступа track to track:                0.2 мс       0.5 мс       0.8 мс
Среднее время задержки (Latency):        2 мс         2 мс           4 мс

на первой странице данной темы было написано:

Олег писал(а):

форум с тремя сотнями активных пользователей онлайн в часы
пик - это не "всеголиш форум". В настоящий момент сервер работает
на двухъядерном Athlon64 X2 3800+ с тремя гигами памяти на борту.
При этом физическая память регулярно исчерпывается,
загрузка процессора большую часть времени составляет 100%.
Я думаю, судить о тормозах по вечерам можно не по наслышке,
в это время системе приходится обрабатывать около сотни запросов к БД единовременно.

Оставим пока загрузку процессора и оперативной памяти а рассмотрим около сотни запросов к БД единовременно

Делаем предположение что БД нормализованна, файлы БД не имеют фрагментации и равномерно разбросаны по HDD,
каждый запрос обращается только к одной таблице БД и ОС уже знает в каком диапазоне секторов лежит каждый файл.

Тогда получается - один запрос к БД - это чтение двух файлов (индекса и данных) - то есть 2 обращения к HDD.
Найдём время, необходимое, для позиционирования головок HDD для подготовки чтения 200 файлов:
(3.5 мс + 2 мс)*200 = 1100 мс - ST373455LC
(3.9 мс + 2 мс)*200 = 1180 мс - ST318452LW
(8 мс + 4 мс)*200 = 2400 мс - ST3400832NS

А если диск фрагментирован? А если запросы не к одной а к 2-10 таблицам? А если база не нормализованна?
Ну и как? Результат впечатляет?
Я не даром привёл здесь, для сравнения, винт 7 - летней давности и обычный SATA - это Вам для размышлений.
А вот теперь и подумайте - избавитесь ли Вы от "тормозов" на той конфигурации, которую собираетесь покупать?
По поводу кеш памяти контроллера - даже и не надейтесь - они (контроллеры) "умные" и такую активность оценивают
как Average Access и кеш не используют.

Возраст: 36 C нами с 22.01.2006 Репутация: **256.8**

zelen, а причем тут HDD если файлы DB к которым всё время обращаются частично кэшируются самой базой данных + кэш диска операционной системы...

Или вы свято верите, что каждый раз база обращается к диску ? Весело

C нами с 15.04.2005 Репутация: **133.2**

Боюсь что всё не так радужно. Запросы к БД сложней чем простое обращение по индексу и чтение энного количества данных. SQL-запросы скриптов форума по большей части нелинейные и имеют достаточно сложные критерии выборки, поэтому прежде чем начинается собственно чтение данных с диска (или из кэша, что, впрочем, нам фиолетово) движок БД должен облопатить кучу данных, сформировать деревья поиска, хэши и прочую служебную требуху, которые упростят и ускорят следующие запросы — на это тратится процессорное время и память. И не следует предполагать, что если вся БД помещается (по физическим размерам) в RAM то это значит что она всегда будет в кэше — это не так, во время работы движка БД формируется множество всякой служебной и сопутствующей информации которая активно лопает память и вытесняет данные из файлового кэша (не напрямую, конечно, известные мне ОС уменьшают дисковый кэш в пользу приложений). Не забываем про кучу процессов крутящихся помимо движка БД, они тоже хотят память. Ну и тому подобные явления, новая служебная информация вытесняет более раннюю, что, при повторном обращении, вызывает повторные перестроения и т.п. Увы, "один запрос к одной таблице БД" может вызвать множество обращений к диску, к разным файлам и в разных местах.