Новый сервер Авиабазы

Насчёт нагрева - особенно для 1U-систем, да ещё в неопределённых условиях хостинга - лучше изначально постараться уменьшить источники тепла, чем ставить больше вентиляторов... которые ставить некуда.

А какой опыт работы с Читами? Насколько надёжны? Это я к тому, что я бы скорость системы поднимал добавлением памяти (а может, 2 Гб поставить?), а не быстрым винтом. Память не так греется...

ruh>Может SCSI всеже от IBM, ну меньше греются?

Ну, как сказать. Барракуды и Читы - это бренды, проверенные годами. Возможно, это личное пристрастие, сам их не юзал, но долгое время эти имена произносились с придыханием и мечтательным взглядом в потолок

ruh>Гепард это по терморежиму печка поверьте.

Дык, 15000 rpm. Я же говорю - нужна минимальная латентность. Те же форумы - это безумная нагрузка в виде чтения большого числа мелких кусочков, порой, тысяч файлов. Иногда - десятков тысяч.

ruh>А так спереди вентиляторы обдува винта, а сзади центробежник в слоты(сколько их там)

Ну, я ж говорю, что сборку начну с покупки корпуса

ruh>вечная машинка получится, а CD без надобности, т.к. как я понял настраивать все едино на дому.

Именно.

avmich>Насчёт нагрева - особенно для 1U-систем, да ещё в неопределённых условиях хостинга - лучше изначально постараться уменьшить источники тепла, чем ставить больше вентиляторов... которые ставить некуда.

Согласен, но нахрена нам холодный, но мёртвый? В том смысле, что не хочется повторения истории с Юкой уже на нашем сервере.

avmich>А какой опыт работы с Читами? Насколько надёжны? Это я к тому, что я бы скорость системы поднимал добавлением памяти (а может, 2 Гб поставить?), а не быстрым винтом. Память не так греется...

Даже 2Гб не спасут, когда системе вдруг захочется освежить кеши. Нагрузка же неравномерная, кеширование не спасёт. Те же форумы могут пару суток пастись на 10% объёма файлов базы, а потом разом пробежаться по всй сотне. Например, пара поисковиков захочет порыться - и труба...

Я смотрел по спецификациям в свое время - ток они одинаковый сосут. Если, конечно, идет речь о подобных моделях. Если сравнивать 7200 с 10000, то не одинаково.
А значит, одинаково и греются.
Потому как инфа не имеет тепловой эквивалент

=KRoN=>Ну, как сказать. Барракуды и Читы - это бренды, проверенные годами.

Честно говоря, я не замечал разницы между IBM и Seagate.
Только в форме корпуса

А так, да, я тоже так считал, потому как исключительно Чит покупал для райдов.
IMHO, в случае RAID'a oт контроллера больше зависит.
И по принципу KISS следует без него обойтись, поставив одиночный винт

Кстати, я бы поставил своп на идешном винте

С Гепардами опыт работы печальный и это еще при 10000 оборотов. Там ленточка была - расплавилась и кирдык не только винту, но и гарантии на него. Рабочая температура за 60 градусов. А вот баракуду с Гепардом не сравнить. Баракуда логическое развитие серверного винта, а в Гепарде в жертву быстродействию принесено все, по типу раз такой крутой, что осилил такой винт, так уж осиль и просторный корпус с приличным охлаждением. К IBM отношение как к Баракуде, но только холоднее оне.
На счет не греются процы, так посмотрите на радиаторы и вентиляторы к ним. Словом нужно будет вывести термоконтроль на дом, чтоб свистел коли чаво не так и вырубался до подхода KRoNа.

Да ладно! Да, задержка на 'подход' данных упадет в полтора раза. Но она и так на порядок меньше времени позиционирования. А его фиг сократишь - переходной процесс и все такое. Не, лучше взять сказюшник IBMовский 10000 ил даже 7200, объемом побольше, да дефрагментировать почаще. А на сэкономленные деньги - памяти сколько влезет.

Относительно десятков тысяч - так что, они разве не базой данных сделаны? Тот же MySQL замечательно работает. Ему еще добавить кэширование результата работы в файлы (типа write-through - если обновляется ветка форума - файлы этой ветки чикаются, если редактируются - чикаются только конкретный кусок содержащий редактируемый файл, а за выдачу отвечает скрипт, который если файл есть - отдает файл - 'страницу' форума, если нет - генерит файл из базы, пишет его на диск и отдает его) - и вообще полный телемаркет будет. С двухгигабайтной базой он точно работает - проверенно.

ruh>Может SCSI всеже от IBM, ну меньше греются?

Да и sustained transfer speed у них один из самых высоких. Например,
но мы, неверно, такой не потянем.

hcube>Относительно десятков тысяч - так что, они разве не базой данных сделаны?

Нет, Plain/text. Исторически UBB - доска для "низкобюджетных" хостингов без MySQL.

hcube>Тот же MySQL замечательно работает.

Ну, сейчас на MySQL сделано некоторое кеширование. Но кеши имеют склонность иногда вычищаться После чего идёт ещё более жестокая загрузка машины, пока они пересоздаются...

Почему всё не в MySQL? За те несколько месяцев, как он появился - я уже раз пять терял некоторые таблицы. И один раз - по моей прямой ошибке. С текстом такое допустить труднее.

hcube>если обновляется ветка форума - файлы этой ветки чикаются, если редактируются - чикаются только конкретный кусок содержащий редактируемый файл, а за выдачу отвечает скрипт, который если файл есть - отдает файл - 'страницу' форума, если нет - генерит файл из базы, пишет его на диск и отдает его) - и вообще полный телемаркет будет.

Ну, что-то в таком духе и сделано. Только там всё ещё сложнее - результаты и на диске в готовом HTML кешируются, и пакованные gzip'ом, чтобы не перепаковывать на лету и т.п.

hcube>С двухгигабайтной базой он точно работает - проверенно.

Там не столько от объёмов, сколько от числа записей зависит. И сложности запроса.

Mishka>Да и sustained transfer speed у них один из самых высоких.

Этот параметр, как раз, совершенно нам не важен

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

Была когда-то у IBM одна модель винчестера. Каждые сутки она останавливала шпиндель на 10 минут, отдыхала, запускалась и работала дальше

Вот Барракуды - те да, изначально предназначены для серверов.

И еще одно соображение. SCSI имеет большой смысл тогда, когда на шине висят много устройств, работающих параллельно. Если будет всего один [рабочий] диск - может, не заморачиваться и оставить его IDE?

GrayCat>Вы, народ, учитывайте, что хардам придется работать практически непрерывно. Многие IDE диски на такое не рассчитаны. Подшипники изнашиваются, смазка выдавливается и т.п.

То, что SCSI будем ставить - это уже однозначно. По деньгам укладываемся.

GrayCat>И еще одно соображение. SCSI имеет большой смысл тогда, когда на шине висят много устройств, работающих параллельно.

Они и нагрузку на процессор меньше дают. И время отклика у них, как правило, меньше.

GrayCat>Если будет всего один [рабочий] диск - может, не заморачиваться и оставить его IDE?

Начал за здравие, кончил за упокой

IBM против Cheetah -

Не репрезентативно, но интересно

KRoN, а может не надо гепарда, а? Греется очень. За теже деньги 5 RAID можно на IDE получить, что неизмеримо надежнее и быстрее. А вот с двухпроцессорной платой товарищ прав. Тоесть они-то работают на одном проце без проблем, только где гарантия, что когда доживем найдется такой же проц? А на разных ни одна не пашет, тоесть велика вероятность апгрейдить оба.
Если не секрет сервак будет покупаться или собираться?

avmich>а апгрейд потом... тогда уж потом оба процессора ставить новых?

Да, почему бы и нет? Процессоры - не самое дорогое. Кроме того, если сейчас взять те же Xeon 1800 - их НАДОЛГО хватит

avmich>Я бы уже с самого начала хотя бы 1 Гб ОЗУ поставил.

Я тоже так считаю.

avmich>Крон, а если в памяти держать кэши всех последних страниц всех форумов - наверное, нагрузка на диск меньше будет?..

Нет, основная нагрузка на винт ложится при полной очистке всех кешей, в т.ч. в SQL-базе, пока идёт переиндексация. Но это бывает редко. Гораздо чаще не хватает просто оперативки. У Юки сейчас всего 512 и не расширить - i815 на мамке. Машина уходит в своп и ложится.

ruh>KRoN, а может не надо гепарда, а? Греется очень.

На эти профессиональные мамки можно, порой, до десятка шасси-кулеров прилепить.

ruh>За теже деньги 5 RAID можно на IDE получить, что неизмеримо надежнее и быстрее.

RAID-5, по отзывам юзавших, тормоз. По крайней мере сильно тормознее RAID-0. А по скорости Чита делает 4-хдисковые RAID на IDE - см.


ruh>А вот с двухпроцессорной платой товарищ прав. Тоесть они-то работают на одном проце без проблем, только где гарантия, что когда доживем найдется такой же проц?

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

Хотя я, всё же, за то, чтобы машину брать сразу "укомплектованную".

ruh>Если не секрет сервак будет покупаться или собираться?

Собираться.

Завтра/послезавтра будет окончательно ясно, но, кажется, $1900 мы тянем. Так что вопрос будет не в урезании железа, а в области возможных "перетасовок" - на чём-то убавить, что-то прибавить.

GrayCat>Вы, народ, учитывайте, что хардам придется работать практически непрерывно. Многие IDE диски на такое не рассчитаны. Подшипники изнашиваются, смазка выдавливается и т.п.

Это справедливо для обоих типов. Механика у них практически одинаковая. Разница, в первую очередь, в электронике. Было, правда время, когда нароботку на отказ пытались (MTBF) для IDE понизить, но был крупный скандал (WD тогда пострадал очень сильно).

=KRoN=>Кто-нибудь знает, мамка SE7500CW2SCSI как с установкой в произвольный 1U-корпус? А то родной Интеловский SR1300 за $500+ мы не потянем

Нормально - смотри, например, http://www.1hotwebserver.com/

=KRoN=>Кроме того, только урезанный поисковый индекс форумов весит более 60Мб и даже простой SQL-запрос в них идёт секунды. Чуть более сложно - уже до десятка секунд. А если представить, как всё это разрастётся ещё через год?

Рома, а где-нибудь и как-нибудь можно взглянуть на схему БД? Да и на сами данные охота посмотреть - можно?

О и, если можно, то и на типичные SQL-запросы тоже. А так же на типичные зависимости.

Mishka>Рома, а где-нибудь и как-нибудь можно взглянуть на схему БД? Да и на сами данные охота посмотреть - можно?

Ну... Могу только посоветовать с MySQL Cluster 7.2 скачать свежий MySQL под Win32 (он бесплатный) и поглядеть "вживую". Дело в том, что я не специались по архитектуре БД и не знаю, на что обратить твоё внимание. Базы у него хранятся - одна база - один каталог. Одна таблица - один файл. Естественно, все из себя индексированные и хешированные.

Mishka>О и, если можно, то и на типичные SQL-запросы тоже.

Типичные:

SELECT * FROM Forum14_cache WHERE topic_id='892';

UPDATE avia_top_pages SET start=start, count=count+1, last=UNIX_TIMESTAMP() WHERE url='http://www.aviation.ru';


Последний так более сотни тысяч раз в сутки выполняется...

При каждом обновлении топика типа такого:

UPDATE Forum14_cache SET stat_line='A||||0||<Unknown [Автогенерация]>||Lockheed S-3 Viking||||||||<Unknown [Автогенерация]>||', last_text='Z||000000||<Unknown [Автогенерация]>||01-22-2002||03:54 PM||||Комментарии и обсуждения страницы Lockheed S-3 Viking.

Убедительная просьба писать сюда только по теме, касающейся данной страницы!||217.106.234.229||unreg||||<Unknown [Автогенерация]>||||no', modified=UNIX_TIMESTAMP() WHERE topic_id='892';

В поисковой системе:

SELECT * FROM forums_indexes WHERE ((text_index LIKE %Су-27% AND text_index LIKE %вооруж%) AND id LIKE '/forum/1/%') ORDER BY modified DESC LIMIT 20,20

Mishka>А так же на типичные зависимости.

Э... What?

KRoN, по Гепарду в U1 заключение фирм собирающих серваки на потоке однозначное нет, т.к. сильнее греется и менее отказоустойчив. Лучше уж фуджик. Те ссылки на которые ты ссылаешься, не в тех корпусах. Сегодня-завтра буду иметь более подробные рекомендации и спецификации. В этих корпусах второй-то винт проблема.

Кто-нибудь знает, мамка SE7500CW2SCSI как с установкой в произвольный 1U-корпус? А то родной Интеловский SR1300 за $500+ мы не потянем

KRoN, здесь важны не личные впечатления и абстракция лучше-хуже, а опрос знакомых по фирмам имеющих большой оборот, тоесть знающих статистически значимый процент возврата. Он сильно пляшет по годам и моделям. У меня и моих знакомых были периоды когда говорили сигейт и только сигейт, но были и когда при слове сигейт кривились губы. То же и фуджами и с вестернами. С IBM чуть лучше, т.к. причины их подыхания были выяснены и определялись не браком.
Я лично с U1 дела мало имел, посему начал консультироваться и на текущий момент получил рекомендации на IBM. При чем рекомендации по терморежиму и надежности, нароботке на отказ и возврату. Затем в списке стоят фуджи, а уж после баракуды, ну и чита.
На U1 c IBM серваки собирают с 2.5 годами гарантии и не запрещая лазить в корпус самому.

ruh>KRoN, здесь важны не личные впечатления и абстракция лучше-хуже

Я за годы админства привык доверять интуиции

ruh>а опрос знакомых по фирмам имеющих большой оборот, тоесть знающих статистически значимый процент возврата.

С этим не спорю, но у кого есть такая статистика?

ruh>С IBM чуть лучше, т.к. причины их подыхания были выяснены и определялись не браком.

Насколько это статистика, а не твои личные воспоминания об отзывах?

ruh>и на текущий момент получил рекомендации на IBM.

Это уже конкретнее. Спасибо.

ruh>На U1 c IBM серваки собирают с 2.5 годами гарантии и не запрещая лазить в корпус самому.

Ну, с Читой и 3 года гарантии есть сервера, так что это не показатель, думаю.

Mishka>>Рома, а где-нибудь и как-нибудь можно взглянуть на схему БД? Да и на сами данные охота посмотреть - можно?

=KRoN=>Ну... Могу только посоветовать с MySQL Cluster 7.2 скачать свежий MySQL под Win32 (он бесплатный) и поглядеть "вживую".

Я имел ввиду структуру твоей базы - database scheme - список таблиц, список полей в каждой таблице и их типы, индексы, права доступа и тд.

Mishka>>О и, если можно, то и на типичные SQL-запросы тоже.

=KRoN=>Типичные:
=KRoN=>
=KRoN=>SELECT * FROM Forum14_cache WHERE topic_id='892';

=KRoN=>UPDATE avia_top_pages SET start=start, count=count+1, last=UNIX_TIMESTAMP() WHERE url='http://www.aviation.ru';
=KRoN=>

=KRoN=>Последний так более сотни тысяч раз в сутки выполняется...

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

=KRoN=>В поисковой системе:

=KRoN=>SELECT * FROM forums_indexes WHERE ((text_index LIKE %Су-27% AND text_index LIKE %вооруж%) AND id LIKE '/forum/1/%') ORDER BY modified DESC LIMIT 20,20

здесь буду думать. Тяжелый это очень SQL.

Mishka>>А так же на типичные зависимости.

=KRoN=>Э... What?

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