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 чуть поправить.
Если мы за 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
когда получишь доступ к подобному железу, то сможешь пощупать его на практике.
Не, конечно, надо пояснять... а то чего в репу посыпалось.
Сетевая карточка с TCP offload несет на борту соответствующий RFC стек, так же при грамотном прошивоне она превращается в аля accf_http, что разгружает хост по большинству основных моментов связанных с сеткой. SCSI RAID с хорошим буффером, к примеру в полгига, даёт пиковую производительность по чтению/записи более 200 мегабайт в секунду на полном рандоме... хотя видали конфигурации где под 300MB/s даёт. На машинку ставится php опкод кэш, который практически всю прекомпиленную воблу держит в оперативке... и вот на такой конфигурации вобла может спокойно дать конкуренцию в несколько тыщ параллельных сессий к одному топику... а если она это может, то и к остальному тыщ 5 в совокупности даст гарантированно. Речь идет о нагрузке большей чем у SE в несколько раз.
А после появление антивируса Касперского вирусов стало больше... и что тут такого?
У этого провайдера есть свой ДЦ - datahouse.su.
У этого провайдера есть свои канальные мощности - citytelecom.ru
В отличии от остальных хостингов на colo и дедиках неработоспособность этого провайдера очень критична.
живет в скромном джейлике на скромном серверочке и тюнинга самой SMF ноль.
Одного сервера для SE достаточно. Сетевушку с full offload, scsi рейдик с хорошим буфером и один двухголовый камень... ну и памяти там не более 4 гиг... три SE можно повесить.
в лидерхосте еще аккаунтинг есть нашей разработки - если какой-то конкретный скрипт будет жрать ресурсы, то есть возможность узнать какой именно и на каких параметрах.
Про второго ничего не знаю, а вот у первого достаточно добротно.. сервера скажем так не под хостинг надо юзать, а под что-то более крутое - с очень большим запасом все.
