Сколько ресурсов может кушать форум SE?

Если мы за FreeBSD говорим, то ничего там по разному тюнячить не надо... по дефолту оттюнячино более чем, но любители могут под mysql пару опций в ядро включить и data size поправить. Основная ошибка начинающих админов в том, что они не обращают внимание на максимальный размер сегмента с данными, который по дефолту 512MB на процесс, что само собой делает невозможным настройку mysqld под размер базы ибо больше 512MB его "разосрать" нельзя... в malloc ему откажет короче и он как-то в этой каше будет и вариться.

Далее по списку - при хостинге форума такие вещи как sendfile и mmap второстепенны и их тюнить не надо (полный список того чего тюнить рекомендуют можно в man tuning глянуть). От дефолта мы правим только размер сегмента с данными (в loader.conf), somaxcon, различные tcp опции на тему rst (хотя они к задаче никакого отношения не имеют) в sysctl.conf, далее мы закидываем в loader.conf загрузку accf_http... буферов под sendfile можно выделить чуть позже и надобность можно глянуть в netstat -m, как и прочих mbufs и т.д... так же в loader.conf мы лочим дисковый кэш мегов на 512... с диковым кэшем тема отдельная еще, т.к. есть машинки где он не дает прироста по конечной производительности, т.к. есть еще гиговый кэш прямо в контроллере, который виден через шину, а не через scsi шлейф... в этом случае дисковый кэш вообще лучше убрать до 128MB и скормить эту память базе.

Собственно о чем я... на SE я не видел более 1000 человек одновремено (плюс/минус короче)... что само собой подразумевает дибильную методику учета от воблы, т.е. там за период времени в 15 минут, что в цифры перевести можно чисто гипотетически... пускай это будет 200 пользовательских запросов в секунду... не важно на каком вебсервере мы это строим, т.к. все передовое использует sendfile, а дефолтных буферов под статику от воблы должно хватить.... собственно дальше мы делаем небольшой хак воблы, а конкретно переводим её на innodb и получаем отсутствие гемороя с локингом базы при многочисленных форумных постах... ну можно еще в одном месте с трансакциями поправить, что бы в момент постинга совсем ничего не лочило... память mysql-ю само собой кормим в сторону innodb. Ну и мегов 200 SHM кормим в сторону php опкод-е кэш-а, в который вся эта прикомпиленная вобла влезет с мегазапасом.

По хорошему еще надо добавить патч на accf_http, который разрешает ему обрабатывать POST запросы до определенного размера или как вариант добавить акселерацию fastcgi под nginx... первое мне нравится больше, т.к. оно более универсально... что бы лишний раз не думать, надо в первом обрабывать все до 64кб, а это на 2k конектов всего 128 метров в р-не mbuf-ов... ибо в большинстве случае медленные клиенты не делают пост-ов более 64Kb...

Можно и внешнюю корзину поставить... тут графики практически линейные получаются и речь идет про получение высокой скорости по I/O на нашем объеме с данными. Если взя база со всеми причендалами пролезает в оперативную память, то зачем нам городить корзины?

Если наш форум пролезает в 4Gb, то зачем нам какие-то рейды? Был один клиент у меня - маньяк помешанный на оперативке... собственно дотыкаем еще 4Gb в хост, фик с ним с pae, poe и т.д.... при старте копируем базу в мемдиск, далее скриптом лепим ляпоту из geom и приближенного софта и в итоге получаем девайс работающий по принципу - запись и на хард и в память, а чтение только из памяти... ну ляпота для надежности, на случай сбоя какого-то... можно конечно скриптом из памяти забирать, но тогда можем нарваться на серьезную ошибку при рековеринге innodb или myisam.

Еще можно поставить четвертый сервер, под раздачу смайликов и тоже под нджениксом.

ps. а вообще один только перевод воблы на innodb увеличивает мощность решения в разы...

man tuning, man geom, man gmirror, man md

1. Копируем на тестовый серв базу рабочего форума.

2. Временно включаем на рабочем сервере log-update.

3. Через полчаса выключаем log-update и копируем получившийся лог на тестовый серв.

4. На тестовом выполняем команды:

mysql --execute="CREATE DATABASE vb_db_innodb"
mysqldump --add-drop-table --add-locks --single-transaction --compact --skip-comments -d vb_db_myisam | sed -e "s/MyISAM/InnoDB/g" | mysql vb_db_innodb (имена баз пишем свои)

5. Поочередно запускаем:

mysql vb_db_myisam < log-update
и
mysql vb_db_innodb < log-update.

6. Смотрим, думаем.

ЗЫ. Количество лочащих базу запросов в реальной работе vb совсем невелико и мало влияет на производительность.

Lupus, в СУБД есть ряд атомарных операций, которые ну никак не могут обходится без каких-то блокировок... какая-то часть этиз операций в mysql реализована на уровне блокирования таблицы... при этом я даже сейчас не беру в расчет блокировку идексов, что обсудить конечно стоит... так вот каждый update таблицы с мессагами вызывает её блокировку! т.е. если на SE устроить флеш моб под названиями "дружно редактируем свои мессаги", то эти три сервера упадут к хренам.... вернее не упадут, а станут в коленолоктевую... разница между innodb и myisam в том, что в одном случае блокировка на table level, а в другом случае на row level... но и с row level тоже не все гладко, т.к. есть такая функцилональность как подсчет количества мессаг, а следовательно тот самый select который их считает блокнется на том самом row, который в данный момент сейчас update... вот тут надо рашпиль взять и чуток с трансакциями подмухлевать, так сказать воспользоваться всей прелестью версионника...

Короче есть хорошие COUNT, а есть плохие... в случаях с myisam count(*) отрабатывает волшебно, чего не скажешь про innodb и т.д... с точки зрения оптимизации и эффективного использования query cache, который кстати в качестве ключа запросы с учетом регистра букавок использует, добавление calc found rows позволяет выгребать статистику из кэша фактически...

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

ps. И getnew чуть поправить.

2kostich

Читал и улыбался .. немножко мечтал .. вспоминал себя лет пять назад..

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

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

2. 1000 пользователей одновременно на сайте генерят далеко не 200 запросов в секунду.. пусть меня поправит господин Lupus но думаю что ОДНОВРЕМЕННЫХ коннекшинов у него в такие моменты около 3-5 тысяч.. и на таких цифрах сервер(или отдельно запущенный ндженикс) под отдачу статики становиться очень и очень актуальным .. я бы сказал необходимым..

3. Попробуйте повесить базу хотя бы в гиг в мемодиск , настроить на копирование его на винты .. ну скажем раз в 15 минут(хотя для систем статистики это уже критично) и сравнить производительность со сказями. И Вы будете просто неприятно поражены.

PS: в разрезе всего этого очень порадовала Ваша подпись :)

Если мы спустимся до атомарных операций, то конкуренция обращений к данным останется лишь между физическими threads. А она никак не зависит от формата базы.

Не изменится вообще ничего. Записи в таблицу постов составляют ничтожную часть всех update таблиц. При каждом обращении, даже бота, апдейтится масса таблиц: количество просмотров треда, даты последней активности, таблицы сессий и многое-многое другое.

Поэтому, проще проверить, как я описал и убедиться, что ни о каких различиях в разы речи нет.

Есть еще один момент: каналы до клиентов разные и без фронт-энда постоянно висит толпа потомков апача, ждущих очередного ack.

это ложное утверждение. между row level locking и table level locking разница существенная. при одной нитке её конечно же нет, а вот при двух она уже прослеживается... а при четырех она уже заметна визуально...

Lupus, кто-то выше писал, что блокирующих операций в вобле нет, а сейчас он пишет о том, что при любом hit производится масса update's.

если ты заметил, то я выше писал про карточки с TOE, а кто-то выразил свою любовь к забавным теоретикам... если мы отдаем ответ и он пролезает по всем параметрам, то мы закрываем этот сокет и дальше уже с ним разбираются драйвера, TOE и т.д... а потомок апача ждет очередного accept... и еще одно ложное утверждение есть - апач не ждет очередного ack, т.к. это уровень стэка.... man write, close, shutdown и про SO_LINGER еще можно почитать.

А некоторые TOE девайсы прошу заметить тянут до 64k сокетов. при тестах раздачи из кэша мы вытянули из этого порядка 400 мегабит на slow конектах на более чем 20k активных сокетах, на каком-то сраненьком писюке, правда с нормальной шиной... о чем уж нам, теоретикам, по существу тут говорить... практики предпочитают отдельный сервер вместо сетевушки за 500 у.е... мы когда солюшены билдим, то руководствуемся и стоимостью эксплуатации за период - в случаях с отдельным сервером процентное выражение существенно заметно.

ps. Можно под nginx держать с php as fastcgi.

Ага. Если читать глазами, то я не утверждал, что их нет, а говорил про относительно небольшую их долю в общем количестве запросов. Другие пишущие запросы я указал, чтобы просветить собеседника, полагающего, что апдейт базы происходит лишь при редактировании постов. ;)

Пойду-ка я лучше работать: трындеть - не мешки грузить... 🚬

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

Lupus, я понимаю конечно что ты и дальше будешь утверждать, что при юзании воблы на myisam и innodb разницы нет, но вопрос напрашивается... а ты это пробовал? Мне кажется в теории только... люблю теоретиков - они забавные.

удачи.