"Лаборатории фантастики" нужен новый сервер

Администрация сайта "Лаборатория фантастики" собирает средства на новый сервер. Подробности приведены на самой первой странице.

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

Если сочтёте, что вкладываться стоит - дайте объявление об этом где-нибудь ещё (когда и если уместно). Спасибо.

Комментарии

Зашел прикинуть нагрузку.
20К зарегистрированных пользователей - негусто.
Рекорд online-посещаемости: 84 (17 января 2009 г. 20:54)
При этом они хотят 5К на сервер. Оба либрусечных стоят 1К максимум вместе, и любого из них с запасом хватит на такую тусовку.
Может им просто друпал поставить?

значения: среднесуточные
февраль 2009 г. январь 2009 г. в среднем за 3 месяца
Просмотры 71,697 68,478 67,946
Посетители 9,073 9,589 9,736
Хосты 9,283 9,616 9,728

совсем не густо, примерно 10% от Либрусека. Celeron + 1G RAM за 300-400 должно хватать, мне год назад хватало. Зачем им десять серверов?

У них самодельный CMS. Видимо, да, незачем лишний раз изобретать велосипед.

Процитирую ваш ответ там.

Прокомментирую немного, как человек причастный:

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

Ресурсы в основном жрёт математика, которую следует обсчитывать оперативно. Сам же сайт (CMS у нас, кстати, нет как таковой, с точки зрения быстродействия это и лучше), т.е. библиографии, форум, и т.п., кушает немного. СУБД, кстати, тоже ест не так много. Установка всяких nginx-ов и подобные действия особой пользы не принесут, единственное, заметное сокращение накладных расходов даёт переход на modperl, но в нынешний сервер больше 4 гиг не лезет, а их ему мало (проверено). Что касается регулярных вычислений, то их перенос на соседнюю машину, несомненно, будет полезен, что мы и планирует сделать. Однако ситуацию это сильно не улучшит, просто кол-во зависаний несколько уменьшится.
Средняя нагрузка на машину вполне нормальна, речь действительно должна об обеспечении пиковой производительности.
Что касается планов на будущее - текущий сервер брался в конце 2006 года с расчётом на два-три года. Если динамика роста популярности сохранится, новый сервер скорее всего продержится столько же. Это, в принципе, нормальный срок жизни высоконагруженной машины. Да, сейчас у нас стоит c2d 2.4ГГц с 4 ГБ ОЗУ.
По оптимизации - да, исторически сложилось так, что сайт во многих местах неоптимален чисто идеологически, дальнейшее вылизывание кода даст хорошо если единицы процентов прироста производительности. Возможно, полностью переписав сайт, мы сможет получить прибавку в десятки процентов, но это чрезвычайно сложная задача и она практически неразрешима в авральном режиме - большая и сложная база данных, более 100000 строк кода.
Насчёт дороговизны сервера - да, мы хотим взять не самое дешёвое зарекомендовавшее себя железо, с которым у нас есть опыт работы и уверенность в его надёжности и производительности. Да, можно сэкономить и купить аналог местной наколенной сборки или вообще собрать самим максимально дешёвое нечто. Вот только на мой взгляд подобный подход значительно менее честен по отношению к людям, помогающим нам своими деньгами. Естественно, гарантируется полная прозрачность затрат, все желающие смогут увидеть отчёт о закупках.
Ну и покупка нового сервера, естеcтвенно, не будет означать, что мы сложим руки и не будем больше улучшать производительность программ, наоборот на новом сервере уже запланировано принять ряд мер, ведущих к увеличению производительности, так как на живой системе многие вещи делать элементарно опасно.

larin, я объясню зачем.
В фоновом режиме пересчитывается почти 10 миллионов корреляций, они же используются для раздела рекомендаций, который юзается всё более часто, реиндексируется форум с учётом морфологического анализатора, пересчитывается база лингвистического анализатора (огромные таблицы с порядка тысячью полей в каждой) с определением авторства текстов, пересчитывается статистика, кеши...
ФантЛаб - это Лаборатория, а не просто сайт, в котором посещаемость является первопричиной нагрузки, и которому, понятно дело, Селерона хватит с лихвой.

Может, решением было бы вынести всю математику на отдельный сервер, чтобы спокойно считала, пусть не так оперативно, но не нагружала сервер?

Иначе вопрос - когда количество текстов станет таким, что вновь перестанет хватить мощности сервера?

-> creator
ээммм... а зачем в фоне рассчитывать столько, если можно один раз по прочтении юзером каждой книги рассчитывать? Причём можно это делать ночью, не стесняясь отключать сервер на время рассчётов (ну скажем 1 час), производить все пересчёты, как это делают торрент трекеры, поддерживая миллионы юзеров и подводя несколько более простую статистику для них (однако подчёркиваю, torrents.ru, например, имеет 5 млн. юзеров, т.е. в 250 раз больше вашего!).

Почему 10 млн? Там матрица 10х10 и 20 000 пользователей = 2 млн. Причём это в худшем случае. А в лучшем 10 * 20 000 = 0.2 млн, посольку смысл для оценки корреляции между юзерами имеют только диагональные элементы матрицы, видимо только их и нужно вычислять (см. разреженные матрицы, sparse matrices).

Экономим 10 млн / 0.2 млн = 50 раз. Объяснили бы кратко как вычисляется (алгоритм), в конкретных цифрах. Народу много ходит, вполне могут сообразить, где прокол (ну вдруг). Сервер уж больно мощный запрошен, и никакой конкретики на сайте - странно... Я вот об этом сообщении в частности:

Цитата:
Мы (технические админы сайта) долгое время пытались оптимизировать запросы, грамотно распределить задачи по расписанию, заблокировали даже такие поисковики, как Yahoo и Webalta, чтобы не грузили систему. В результате, немногим только выиграли. Вы сами видели, что сервер стал падать чаще. В период посетительской активности, когда, в плюс к тому, поисковики начинают шерстить сайт, сервер не справляется, виснет наглухо. Мы ставили разные системные прибамбасы для оптимизации — стало чуть лучше, но проблему не решило. У нас был вариант сделать модульный апгрейд, но материнская плата у нас лишь однопроцессорная, более «крутые» процы не поддерживает, а по оперативной памяти лимит — 4 Гб. Мы пришли к выводу, что нужно покупать новый, в разы более мощный сервер с таким запасом мощности, которого хватит, дай Бог, на много лет.

т.е. как и что делали неясно, но сервер нужен в несколько раз более мощный. Почему не на несколько порядков? Проблема-то в чём конкретно? Вот здесь (на либрусеке), к примеру, мускул перегружен -> нужен более каменный камень. Сервер более мощный в каком отношении: камень, память, всё вместе? Купить ведь можно и более дорогой, но пока проблема не локализована, можно купить подороже не то...

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

creator написал:
larin, я объясню зачем.
В фоновом режиме пересчитывается почти 10 миллионов корреляций, они же используются для раздела рекомендаций, который юзается всё более часто, реиндексируется форум с учётом морфологического анализатора, пересчитывается база лингвистического анализатора (огромные таблицы с порядка тысячью полей в каждой) с определением авторства текстов, пересчитывается статистика, кеши...

Ну это совсем просто, раз в фоне.
Берём второй сервер, долларов за 400-500.
На нём поднимаем БД и реплицируем туда с основного. Можно не всю, а только нужные для расчётов таблицы - впрочем, при столь скромных объёмах это не важно.
И запускаем расчёт 10 миллионов корреляций и прочего перечисленного.
Как досчитает - ещё раз запускаем.
Первый сервер оптимизируем как вебсервер - ставим nginx, memcached и прочие стандартные прибамбасы.
Такая конфигурация даст запас раза в 3 на первом сервере и бесконечный на втором - по мере увеличения объёмов цикл пересчёта будет занимать больше времени, тормозить главный сервер от этого не будет.

не поленился, прикинул, во что выливаются ваши цифры (грубо)

Пусть 20 тыщ матриц надо посчитать и пусть каждый десятый юзер прочитал по одной книге за день (эту цифру можете взять реальную и пересчитать). Это (20 000/10)^2 = 4 млн. матриц 10х10. Беру свой комп, далёкий от оптимального пакет Mathematica, считаю на 4ом пне, 1.6 ГГц (1 ГБ RAM). Вычисляю корреляцию двух неразреженных (!) векторов размеростью 10 каждый (ф-ция Correlation[]), засекаю время на 10 тыщ заходов: 3.7 сек. Т.е. для 4 млн. это будет пропорционально 400 * 3.7 сек = 25 минут непрерывного расчёта в день. Вот вам неоптимальная цифра в неоптимальных условиях, грубая.

На этом этапе верится, что у вас есть некоторые вычислительные проблемы, если всё-таки больше юзеров рапортует.
1. Подумайте о расчёте только диагонали матрицы (не знаю, может вы ещё что-то с ней делаете и вам нужна полная?).
2. Если не каждый 10-ый юзер прочитывает книгу, а 50-ый, скажем, то цифра будет совсем невидимая. Хорошо бы узнать всё-таки, когда вы запускаете расчёт, т.е. я так понимаю, как часто юзеры оставляют отзывы о книгах.

Извините, что встреваю :)
Но.
Средние числа для оценки качества обслуживания мало информативны.
Нужно смотреть пиковые нагрузки.
Величина интервала для web-сервера - вопрос. Нет у меня пока собственного мнения.
В телефонии из расчёта средней продолжительности вызова 3-7 минут принято смотреть на интервале в 1 час.

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

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

Уточнение принимаю.
Но в несколько иной формулировке: web-сервер существенно отличается тем, что нагрузка формируется не одним, а несколькими источниками. И это необходимо учтывать.
Минимум же нагрузки совершенно не обязательно приходится на ночь.

Но с точки зрения обеспечения некоторого заданного качестве обслуживания (для случая web-сервера готовой формулировки критериев тоже не дам) без рассмотрения пиковых нагрузок обойтись не получится.

X