Сайт ночью спит?

Цитата:

от: Алексеич
Володя, если не секрет, на каком сервере сейчас крутится сайт?

Linux + Apache + PHP + PostgresQL
2x - Opteron 240 (или как их там - кажется 2003 года)
6Гиг оперативки, два софт райда1 - БД+сам Linux на SCSI-73G, картинки на IDE 200G. Иногда приближаемся к ширине канала в 10Мбит, но она ничего не лимитирует.
по данным iostat - диски вообще не используются на чтение - все в оперативке, т.е. уперлись в процы (ну, либо код на С++ переписать :) ). Хочется поставить по крайней мере 4-х процовую конфигурацию (4 проца, либо 2 двухядерника). Ставить Интел не хочется - там IMHO проблемы с доступом в память для многопроцессорных схем. Но есть подозрение, что надо делать несколько серверов под апач с ПХП и отдельно БД. НО: я этого еще никогда не делал (балансировку/кластеры), в Комкор кататься с железками туда-сюда целая история каждый раз, да и 10-20 килобаксов на "эксперименты" и мое образование компания не даст.

Если есть конкретные идеи (только не покупка именно у вас оборудования или переезд на другую площадку - это не в моей компетенции) или вопросы - пишите на volod@foto.ru

Проблема понятна. Вероятно, что тонкое место - не количество процессоров, а то что они сидят на одной шине. Ситуацию может разрулить параллельная обработка запросов. Простейшее решение - кластер из нескольких серверов.

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

Цитата:

от:Алексеич
Проблема понятна. Вероятно, что тонкое место - не количество процессоров, а то что они сидят на одной шине. Ситуацию может разрулить параллельная обработка запросов. Простейшее решение - кластер из нескольких серверов.

Подробнее

Только нужен не вычислительный кластер, а просто набор параллельных апачей на одной БД. Тут мы упираемся в мою компетентность и времязатраты.
Цитата:

от: Алексеич

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

Вбелую собрать деньги и потратить их не подставив ни одно юрлицо у меня никак не получится. :) В нашем НК я некомпетентен совсем.

А администрация фото.ру не увлекается содержанием клуба?

1) Вы используете PHP-акселераторы (IonCube PHP accelerator, Zend)?

2) По поводу распределения нагрузки:
а) самый простой метод - в апаче есть режим "reverse proxy", который можно настроить, чтобы распределять запросы на несколько backend-серверов. Это внесет небольшую задержку на каждый запрос из-за проксирования, что в общем-то не страшно, потому что она потонет во времени соединения пользователя с сервером.
б) чуть-чуть посложнее - через NAT. iptables умеет делать NAT на несколько серверов. Только мне не нравится, как он работает. Загрузка CPU на бэкендах получается разная - чем дальше к концу списка, тем меньше.
в) тот же NAT, только со специализированным софтом - LVS (http://www.linuxvirtualserver.org/Documents.html). В этом у меня тоже все никак нет времени разобраться.

Думаю, стоит начать с (а), конфигурируется легко, могу прислать примеры.
Фронтенд, конечно, лучше отдельный - благо мощности ему нужно немного.

А почему вы используете Postgres, а не MySQL? У нее какие-то серьезные преимущества?

P.S. Еще в таком случае понадобится отдельный сервер под разделяемую файловую систему (через NFS).
Таким образом, надо: 1) N бэкендов; 2) 1 фронтенд; 3) 1 SQL; 4) 1 файл-сервер.
Пожалуй можно совместить 2 и 3 или 2 и 4. Очевидно, лучше не совмещать 3 и 4, у нас когда-то так было, и это иногда вызывало большие проблемы :)

Не знаю, хватит ли на все это 5-6 штук...

Цитата:

от: Volod
Вбелую собрать деньги и потратить их не подставив ни одно юрлицо у меня никак не получится. :) В нашем НК я некомпетентен совсем.

Просто откройте счет в сбербанке на частное лицо

Цитата:

от: Самойлов
1) Вы используете PHP-акселераторы (IonCube PHP accelerator, Zend)?

Нет. У нас php 5 (на странице IonCube версия пхп - 4), а до покупки за 1500$ в год Zend Optimizer еще не доросли. На эти деньги как раз в год можно по серверу добавлять :)
Цитата:

от: Самойлов
2) По поводу распределения нагрузки:

Для этого нужно слишком много серверов сразу, мы пока до такого не доросли.
Цитата:

от: Самойлов
А почему вы используете Postgres, а не MySQL? У нее какие-то серьезные преимущества?

Когда 3,5 года назад переходили с третьего мускла на шестой посгрес были такие преимущества: вложенные запросы, триггеры, функции, "академичность" реализации - постгр ориентирован на абстрактные данные и работу с ними, а мускл как будто сделан для простых запросов на вебе.
Цитата:

от: Самойлов
Не знаю, хватит ли на все это 5-6 штук...

У меня пока два (на втором вся почта всех наших доменов и 20 сайтов, включая магазин фотору), вроде утвердили деньги на третий сервер. В таких условиях о кластере апачей речь не идет. :(

Цитата:

от: Volod
два софт райда1 - БД+сам Linux на SCSI-73G, картинки на IDE 200G.

Возможно отжирание CPU под софтрайд, когда флушатся какие-нибудь накопленные изменения. Попробуй аппаратный райд5 - цена вопроса - контроллер за 210уе от promise и саташные винте.

Volod:
А, ну вот, налицо "забивание гвоздей микроскопом" - PHP5 и "академичный" Postgres для обслуживания форума и несложного магазина :)
Вы сказали, что база падает через три дня работы - а с чем это связано? С исчерпанием места, или с фрагментацией данных, или еще что? Вроде бы если прикинуть частоту добавления сообщений в форум и фотографий - можно предположить, что записи в БД очень мало, 99% работы на чтение. Очень странно. Во всяком случае в mysql4 + innodb какие-то проблемы из-за фрагментации c отдельными таблицами начинаются только после нескольких месяцев работы (и когда счет циклов insert-delete уже идет на десятки миллионов).

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

Цитата:

от: Самойлов
Volod:
А, ну вот, налицо "забивание гвоздей микроскопом" - PHP5 и "академичный" Postgres для обслуживания форума и несложного магазина :)

Ну, магазин связан с очень сложной системой документооборота, склада и т.д. - которая тоже на постгре. С т.з. обучения программистов так гораздо проще. :) Во-вторых, галерея со всеми реализованными функциями не такое и простое дело. Не у всех галерей получение отсортированного по любому рейтингу списка фотографий за "3 года назад" не сильно отличается по скорости от получения последних работ. Да и рейтингов с фильтрами я тут наразводил - под каждое сочетание рейтинга и фильтра надо свой индекс, а такое количество индексов => непрерывная запись непрерывно изменяемых индексов. :)
Цитата:

от: Самойлов

Вы сказали, что база падает через три дня работы - а с чем это связано? С исчерпанием места, или с фрагментацией данных, или еще что?

IMHO: Где-то через три дня накапливается такое количество данных в форуме и галерее, что теряется выигрыш от кластеризации по "частым" индексам. Собственно каждый день надо делать не столько вакуум, сколько кластеризовать данные. Уж как влияет кластеризация на полностью кешированные данные я не знаю. Очень уж база академичная :)
Цитата:

от: Самойлов
Вроде бы если прикинуть частоту добавления сообщений в форум и фотографий - можно предположить, что записи в БД очень мало, 99% работы на чтение.

Записей мало, но из добавляемых записей 99% тут же читаются и без кластеризации они просто ищутся по индексу абы где, т.е. куда запишут (см. IMHO про кластеризацию).
Цитата:

от:Самойлов
Очень странно. Во всяком случае в mysql4 + innodb какие-то проблемы из-за фрагментации c отдельными таблицами начинаются только после нескольких месяцев работы (и когда счет циклов insert-delete уже идет на десятки миллионов).

Подробнее

Может там просто нет выигрыша от дефрагментации :) Черт, не могу не сорваться в спор "чей брэнд лучше" :)
Цитата:

от:Самойлов

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

Подробнее

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

Сегодня помимо прочего сервер перезапускал (76 дней uptime было) - стало гораздо лучше. Т.е. еще и в ядре надо что-то ковырять :(

Цитата:

от: Volod
Цитата:

от:Самойлов
Volod:
А, ну вот, налицо "забивание гвоздей микроскопом" - PHP5 и "академичный" Postgres для обслуживания форума и несложного магазина :)

Ну, магазин связан с очень сложной системой документооборота, склада и т.д. - которая тоже на постгре. С т.з. обучения программистов так гораздо проще. :) Во-вторых, галерея со всеми реализованными функциями не такое и простое дело. Не у всех галерей получение отсортированного по любому рейтингу списка фотографий за "3 года назад" не сильно отличается по скорости от получения последних работ. Да и рейтингов с фильтрами я тут наразводил - под каждое сочетание рейтинга и фильтра надо свой индекс, а такое количество индексов => непрерывная запись непрерывно изменяемых индексов. :)
Цитата:

от: Самойлов

Вы сказали, что база падает через три дня работы - а с чем это связано? С исчерпанием места, или с фрагментацией данных, или еще что?

IMHO: Где-то через три дня накапливается такое количество данных в форуме и галерее, что теряется выигрыш от кластеризации по "частым" индексам. Собственно каждый день надо делать не столько вакуум, сколько кластеризовать данные. Уж как влияет кластеризация на полностью кешированные данные я не знаю. Очень уж база академичная :)
Цитата:

от: Самойлов
Вроде бы если прикинуть частоту добавления сообщений в форум и фотографий - можно предположить, что записи в БД очень мало, 99% работы на чтение.

Записей мало, но из добавляемых записей 99% тут же читаются и без кластеризации они просто ищутся по индексу абы где, т.е. куда запишут (см. IMHO про кластеризацию).
Цитата:

от:Самойлов
Очень странно. Во всяком случае в mysql4 + innodb какие-то проблемы из-за фрагментации c отдельными таблицами начинаются только после нескольких месяцев работы (и когда счет циклов insert-delete уже идет на десятки миллионов).

Подробнее

Может там просто нет выигрыша от дефрагментации :) Черт, не могу не сорваться в спор "чей брэнд лучше" :)
Цитата:

от:Самойлов

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

Подробнее

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

Сегодня помимо прочего сервер перезапускал (76 дней uptime было) - стало гораздо лучше. Т.е. еще и в ядре надо что-то ковырять :(

Подробнее

Поставь виндовс и аксесс и все бут крута!

Цитата:

от: enfant terrible
Поставь виндовс и аксесс и все бут крута!

Т.е., по сути, предложение убить себя апстену? Не щаз.

Цитата:

от: Volod
Цитата:

от: enfant terrible
Поставь виндовс и аксесс и все бут крута!

Т.е., по сути, предложение убить себя апстену? Не щаз.

Да не, вот нафига нужны эти ацтойные линуксы? У майкрософта все атлично работает! :D

enfant terrible:
Ага, работает, да. Спасибо. Был такой, файл-сервер под линуксом. Заменили на линуксовый, слава богу. Разбил бы его ап стенку сам, если бы не на другом конце земного шара стоял :)
А еще как-то товарищ приходил, мучался всю ночь, сидел в терминале, возился... У него Active Directory в компании упал. Вот упал без видимой причины, и все. Конфигурация не менялась, в логах ошибок нет! А не работает. Вылечилось, как всегда, переустановкой виндовс :) :) :)

Volod:
Мда... Вот все думал, думал на досуге. Никогда не сталкивался с проблемами на таком уровне. Выходит все же проблема в реализации конкретного софта (Postgres). То есть замена на MySQL в принципе эту проблему, возможно решит. А может и не решить, или вызовет другие проблемы :)
Подумалось, что возможны такие пути частичного решения - просто мысли по поводу:
1) Всевозможные индексы по рейтингам можно убрать, и генерировать эти списки раз в сутки и хранить в отдельных таблицах. Вряд ли кто-то заметит разницу :)
2) Попытаться минимизировать размер индексов. Разделить старые данные и новые. Время от времени новые перегонять в старые (скажем, те, что старше недели), после чего проводить кластеризацию старых. Новых будет немного, как следствие - индексы небольшие, поиск быстрый. Если надо выбирать сразу из старых и новых, придется делать запрос с UNION из двух наборов таблиц - но это нечасто.

Конечно, не самые красивые решения :)

Цитата:

от: Самойлов
То есть замена на MySQL в принципе эту проблему, возможно решит. А может и не решить, или вызовет другие проблемы :)

Скорее просто поменяются проблемы. :(
Цитата:

от: Самойлов

1) Всевозможные индексы по рейтингам можно убрать, и генерировать эти списки раз в сутки и хранить в отдельных таблицах. Вряд ли кто-то заметит разницу :)

Какие списки? Полмиллиона картинок с несколькими атрибутами (автор, категория, время в т.ч. "все подряд") во всех возможных сочетаниях с сортировками (реки, оценки, оценки ХС, время, количество просмотров, количество комментов, дата последнего коммента) иначе как средствами СУБД и не разрешить :)
Цитата:

от: Самойлов

2) Попытаться минимизировать размер индексов. Разделить старые данные и новые.

К этому я плавно и подхожу, но это применимо только к галерее, а 30% нагрузки обеспечивает форум, на котором никакой архив не предусмотришь (в пределах здравого смысла - за месяц не архив, а за полгода накопится столько, что и выделять поздно). Да и в галерее это можно стало только после того как ввел разделение по суткам.
Цитата:

от:Самойлов

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

Подробнее

Юнион рождает нетривиальную систему подсчета количеств результатов в выдаче. У нас count() на фотографии почти не делается - для всех сочетаний фильтров по категориям, датам, авторам данные триггерами заносятся в разные места (скажем по каждому дню в каждой категории в отдельную таблицу, количество фотографий автора - в таблице авторов и т.д.), разве что фильтр по автору и категории одновременно выполняется на лету - благо данных мало. Так что в этом случае код усложнится настолько, что ни оптимизировать, ни расширять функциональность будет нереально.

Пока я планирую поставить новый сервер для магазина фотору (фотору тоже тормозит, но на это жалуется отдел продаж :) ), а на старом фоторушном организовать поисковик для клуба - нехай работает медленно и перебирает все 1.500.000 постов каждый раз, зато будет почти онлайновый поиск с шаблонами (ну, +задержка на репликацию), "строками целиком" и прочими радостями от seq scan :) Там же и поиск по темам, по авторам, с учетом цитат и без учета и т.п.

Кстати, раз уж тут есть спецы:
3200уе за Intel 1U case + 2xXeon ~3GHz + 4G RAM + 2x 400G SATA это много? И кто может посоветует поставщика? До этого был только самосбор, но лотерея надоела. Лучше письмом на volod@foto.ru

Цитата:

от: enfant terrible
Да не, вот нафига нужны эти ацтойные линуксы? У майкрософта все атлично работает! :D

Работает не у майкрософта, а у конкретного сисадмина. А в винде я ничего не понимаю. Там чуть шаг вправо-влево от GUI, так надо быть очень сертифицированным специалистом, чтобы сделать хоть что-то нетривиальное.

Volod:
Цитата:

Какие списки? Полмиллиона картинок с несколькими атрибутами

Это я краем глаза посмотрел - подумалось, что количество оценок, реки и т.д. используются только для составления списков "100 по...". Сейчас увидел, что списки и автора, и по категории можно сортировать по всем этим критериям... Да, действительно не выйдет.

Цитата:

а на старом фоторушном организовать поисковик для клуба - нехай работает медленно и перебирает все 1.500.000 постов каждый раз, зато будет почти онлайновый поиск с шаблонами (ну, +задержка на репликацию), "строками целиком" и прочими радостями от seq scan

Подробнее

Fulltext-индексы, как в поисковиках? Обновлять правда, в реальном времени, скорее всего, не получится - станет все еще хуже :) Но раз в сутки - вполне можно.

Вот насчет сервера ничего не скажу - у нас все аппаратные вопросы решает хостинговая компания (и делает это очень хорошо), и в ценах я не ориентируюсь. Должны быть тут более компетентные люди.

Цитата:

от: Volod
Цитата:

от:enfant terrible
Да не, вот нафига нужны эти ацтойные линуксы? У майкрософта все атлично работает! :D

Работает не у майкрософта, а у конкретного сисадмина. А в винде я ничего не понимаю. Там чуть шаг вправо-влево от GUI, так надо быть очень сертифицированным специалистом, чтобы сделать хоть что-то нетривиальное.

Подробнее

Там все просто и очень мощно, вот глянь: http://www.microsoft.com/rus/SQL/BigData/Default.mspx :D

enfant,
там не написано, на каком железе все это работает и сколько такие системы стоят :)

Цитата:

от: Самойлов
enfant,
там не написано, на каком железе все это работает и сколько такие системы стоят :)

Да я знаю. Просто прикалываюсь :)