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

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

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

Mishka>Давай, думаю Крон не обидится. Я хочу БД пощупать тоже - если Крон позволит.

Дык, сейчас реальной "загрузочной" базы данных и нет
Только в АвиаТОП'е.

Весьма объёмистая база поисковых индексов используется пока очень редко - поисковая система не популярна.

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

Mishka>Давай, думаю Крон не обидится. Я хочу БД пощупать тоже - если Крон позволит.

Дык, я-то не против, но базы пока сервер не грузят, слишком их мало. Вот, только что, например, разобрался из-за чего глючит переход форумов - у меня раньше было массовое удаление через `rm ...*.cgi`; - а таперь оно стало безумно тормозить, таймауты скрипта раньше кончаются. К счастью, теперь работает unlink <...*.cgi>; - так что всё стало ок. Но ведь есть ещё места, где запуск внешних програм не выкинуть - тот же ImageMagick - PerlMagick не установлен...

А кто мешает делать бэкап базы каждые сутки? mysqldump forum - и через 15 минут у тебя ВСЯ база включая структуру сложена в отдельный файл, из которого на раз-два-три восстанавливается. Один файл. Потом его раз в неделю сархивировать вместе с другими на сидюк - и все!.
Отностиельно кэшей в памяти - IMHO это уже перебор. Надо просто отдать MySQL памяти побольше - 128-256 под индексы, а остальное пусть скушает дисковый кэш.

Относительно же удаления - надо работать ТОЛЬКО по ID ссобщения и всегда верифицировать при этом, тот ли пользователь его рвется редактировать или удалить. Если не тот - гнать его нафиг!

Еще относительно форумов - может, сделать аналог ФИДО? В смысле - ведение индивидуальной странички с показом только непрочитанных сообщений?

KRoN, Р3(1400) с 512 к кэша выделяет тепла в 1.5 раза меньше чем ксеончик(1800), в 1U для двухпроцессорника это критично. Тоесть боюсь наидешевейшим корпусом не отделаешься. Учти, что кулера стандартные под Р4 в 1U и близко не лезут.

KeyOS>Как, что работает я знаю по моему очень хорошо.
KeyOS>5 лет уже с этими самыми потоками работаю и не совсем понял, что такое "появились недавно". Не на линуксах правда, но не из-за того, что там их не было, а по личным предпочтениям.

Да примерно тогда и появились. До этого или на vfork или нити не поддержаные ядром, работавшие в пространстве пользователя и диспетчер был там же. Т.е. о time slice не приходилось говорить. Да и с переносимостью проблемы. POSIX pthreads как раз и был ответом. Кстати, Крон, если будешь переносить свой софт в нити, то иши pthread всякие, а не fork-и.

KeyOS>Вся идея была дать понять, что если есть возможность, то лучше работать с однопроцессорными системами. Просто игра далеко не всегда стоит свеч и потратив лишние деньги можно обнаружить, что дополнительный процессор не помогает.

Ага.

KeyOS>Если хотите могу предложить посильную помощь и попробовать проследить, что и где работает медленно и почему.

Давай, думаю Крон не обидится. Я хочу БД пощупать тоже - если Крон позволит.

На счёт индивидуальной отметки прочтённых/непрочтённых (опционально) у меня давно в планах. А что до id - бывают запросы на массовую модификацию и удаление. Те же кеши всякие и т.п.

Колитесь, кто из Австралии письмо прислал с зоопарком
Некто S.K. - au, это ты?
В общем, деньги по почте доходят

=KRoN=>Колитесь, кто из Австралии письмо прислал с зоопарком
=KRoN=>Некто S.K. - au, это ты?

Я ничего не слал. Если пришло не с прокси моего универа, то и спрашивать не стоило даже

Нет, не с прокси, а по по почте... Бумажной. С баксами внутри

... итак, акция по спасению Авиабазы приобретает поистине международный характер - доллары США, российские рубли, гульдены, франки, зайчики.... свой посильный вклад сделал даже житель Папуа-Новая Гвинея, прислав 4 акульих зуба. Они будут использованы для украшения корпуса нового сервера .

hcube]...свой посильный вклад сделал даже житель Папуа-Новая Гвинея, прислав 4 акульих зуба. Они будут использованы для украшения корпуса нового сервера src=/forum/smilies/wink.gif [image link error].
Рулез! src=/forum/smilies/biggrin.gif [image link error]

Еще шекеля наши родные не позабудьте! src=/forum/smilies/smile.gif [image link error]

hcube>...свой посильный вклад сделал даже житель Папуа-Новая Гвинея, прислав 4 акульих зуба. Они будут использованы для украшения корпуса нового сервера .
Рулез!

Еще шекеля наши родные не позабудьте!

Кроныч, може забацаем свой ISP и фиг с ней с юкой

=KRoN=>В общем, деньги по почте доходят

Не "доходят", а "дошли в этот раз".

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

=KRoN=>Только на дефрагментированной системе и если кеширование идёт с опережающим чтением - обычно при проходе по форумам, сканёжке на предмет новых картинок и т.п. идут однократные обращения к заданным областям.

Нет - обращение к памяти всегда сильно быстрее обращения к дискам, дефрагментация дисков не помогает в достаточной степени, а фрагментация ухудшает результаты дисков. Линукс устроен так, что использует физическую память под дисковые кэши, пока она, физическая память (ОЗУ) не кончится. Поэтому, если все данные уже в памяти, к диску обращения нет (на самом деле, в Линуксе тоже sync работает каждые несколько секунд, если не ошибаюсь, сбрасывает изменения на диск - но это значительно меньшая нагрузка и задержка, чем асинхронный случайный доступ).

Мнение осталось то же - для сервера дополнительная память выгодна и как средство снижения зависимости от характеристик дисковой системы.

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

=KRoN=>>В общем, деньги по почте доходят
avmich>Не "доходят", а "дошли в этот раз".


Я же не сказал - всегда доходят

avmich>Нет - обращение к памяти всегда сильно быстрее обращения к дискам,

Естественно. Только, вот, в памяти инофрмация берётся с дисков. А повторное использование данных в тех самых критичных случаях переиндексации практически отсутствует. Так что если что-то и сможет спасти немного ситуацию, так только опережающее чтение.

avmich>Линукс устроен так, что использует физическую память под дисковые кэши, пока она, физическая память (ОЗУ) не кончится.

Windows тоже давно работает также Точнее, она оставляет резерв и приложениям небольшой, но размер кеша по сотне мегабайт - не редкость

Кстати, раз уж пошли сравнения - в Windows пошли ещё дальше. При запуске Win32-программы она не грузится в память, как в Linux, а мапится на виртуальную память. В плюсы - "мгновенный" старт, в минусы - с exe-шником запущенной программы ничего нельзя сделать, кроме как переименовать

avmich>Поэтому, если все данные уже в памяти, к диску обращения нет

Так оно так в любой приличной OS.

avmich>Мнение осталось то же - для сервера дополнительная память выгодна и как средство снижения зависимости от характеристик дисковой системы.

С этим не спорю Но в случаях массовой переиндексации ресурсов дополнительная память не спасает. Разве что ВСЮ дисковую сситему там хранить

avmich>Ещё мнение - Крон, старайся сделать систему по характеристикам, при прочих равных, ближе к тем системам, с какими ты уже работал - меньше сюрпризов будет. Из практики...

Увы, у меня практики с нагруженными Web-серверами не было - а это очень специфичные системы. Вот корпоративные сервера, файл-сервера, рабочие станции разных назначений - этого не сотни машин... Но в случае сервера Авиабазы весь этот опыт мало стОит...

=KRoN=>Колитесь, кто из Австралии письмо прислал с зоопарком
=KRoN=>Некто S.K. - au, это ты?
=KRoN=>В общем, деньги по почте доходят

Я это. Там же был ник написан на серебрябной наклейке от 5" дискеты . Да и предупреждал я в том форуме, что почтой отправил, ибо WU US$20 попросил. Что-то долго для экспресс-почты шло...

Zeus, круто вы скачете по родному глобусу А что вы делаете в мельбурне, если не секрет?

Хм, массовая переиндексация, по-моему, не должна быть процессом реального времени... а делается иногда и при этом не очень часто...

Вот пример: за, скажем, два часа обновляются тридцать форумных тем. Последние пара страниц тем - в кэше, это же совсем немного. И не надо после каждого сообщения всё переиндексировать...

Или что-то не так? UBB-то позволяет?

avmich>Хм, массовая переиндексация, по-моему, не должна быть процессом реального времени... а делается иногда и при этом не очень часто...

Естественно, она бывает не часто. Последний раз была с месяц назад, когда упали две большие таблицы в MySQL (точно без моей вины, т.к. до того скрипт несколько дней безглючно отработал, а я ничего не менял) - тогда Авиабаза легла на пол-дня.

avmich>Вот пример: за, скажем, два часа обновляются тридцать форумных тем. Последние пара страниц тем - в кэше, это же совсем немного. И не надо после каждого сообщения всё переиндексировать...

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

avmich>Или что-то не так? UBB-то позволяет?

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

avmich>Эти критичные случаи переиндексации - там же чтение вроде идёт не по мелким записям, а большими фрагментами?

По топикам. Один топик - один файл. Посмотри сколько топиков всего на базе - где-то на десятки тысяч (лениво заглавную страницу форумов грузить, я сейчас на тормозном ноутбуке). Объёмы от килобайта до мегабайта. Суммарный объём базы в голом тексте уже давно идёт на сотни мегабайт (при последнем измерении было около 300Мб)

avmich>При любом раскладе это вроде более оптимально. А ежеминутные обращения к отдельным темам - то, что и происходит постоянно - относительно дёшево и диски почти совсем не нагружает.

Да, именно так. Авиабазу убивает не постоянная загрузка - она как раз весьма умеренная, а редкая, но запредельная.

Так её нельзя на другом компьютере делать?

Сейчас вот лежу, перечитываю "Data Warehouse Toolkit" - так там как раз и рекомендуют...

Эти критичные случаи переиндексации - там же чтение вроде идёт не по мелким записям, а большими фрагментами? При любом раскладе это вроде более оптимально. А ежеминутные обращения к отдельным темам - то, что и происходит постоянно - относительно дёшево и диски почти совсем не нагружает.

Zeus>Я это. Там же был ник написан на серебрябной наклейке от 5" дискеты :

Гм. Или я торможу, или наклейка в дороге потерялась Где на неё, хоть, смотреть? Конверт такой пёстрый!

Гы. Ну, давайте скидываться на второй компьютер

=KRoN=>Ну, давайте скидываться на второй компьютер
Тогда уж сразу ещё на два (впрок)!