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

Опубликовано пн, 02/02/2009 - 21:13 пользователем Константин Бояндин

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

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

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

Комментарии

Опубликовано вт, 03/02/2009 - 00:14 пользователем larin

Зашел прикинуть нагрузку.
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 должно хватать, мне год назад хватало. Зачем им десять серверов?

Опубликовано вт, 03/02/2009 - 01:36 пользователем Константин Бояндин

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

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

Опубликовано ср, 04/02/2009 - 18:25 пользователем mzm

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

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

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

Опубликовано вт, 03/02/2009 - 01:35 пользователем creator

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

Опубликовано вт, 03/02/2009 - 01:40 пользователем Константин Бояндин

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

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

Опубликовано вт, 03/02/2009 - 15:03 пользователем bookwarrior

-> 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 раза больше привалит и вы опять окажетесь у разбитого корыта...

Опубликовано ср, 04/02/2009 - 15:25 пользователем larin

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

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

Опубликовано вт, 03/02/2009 - 15:35 пользователем bookwarrior

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

Пусть 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-ый, скажем, то цифра будет совсем невидимая. Хорошо бы узнать всё-таки, когда вы запускаете расчёт, т.е. я так понимаю, как часто юзеры оставляют отзывы о книгах.

Опубликовано ср, 04/02/2009 - 03:07 пользователем Anarchist

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

Опубликовано ср, 04/02/2009 - 05:38 пользователем bookwarrior

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

Опубликовано ср, 04/02/2009 - 09:57 пользователем Anarchist

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

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

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