For shared_buffers, the quick answer is to allocate about 25% of system memory to shared_buffers, as recommended by the official documentation and by the wiki article on Tuning Your PostgreSQL server, but not more than about 8GB on Linux or 512MB on Windows, and sometimes less. However, I've recently become aware of a number of cases which suggest that higher values may perform much better. PostgreSQL uses the operating system's memory for caching, but, as recent performance results have shown, there can be a huge performance benefit to having the entire database in shared_buffers as opposed to merely having it in RAM. Several EnterpriseDB customers or potential customers have reported excellent results from cranking up shared_buffers to very large values, even giving PostgreSQL the lion's share of system memory for its own use. This flies in the face of some conventional wisdom that PostgreSQL doesn't handle large shared_buffers settings well, but enough people have reported good results that it seems worth taking this strategy seriously.
Пока не сталкивались, вакуум в бэкграунде успевал всё вычистить.
Если не будет успевать, можно сделать его более злым, можно раскладывать наши базы на большее количество инстансов постгреса, чтобы счётчики транзакций набивались медленнее.
Решардинг в смысле перемещения пользователей между шардами — такого не делаем.
Решардинг в смысле перемещения шардов на другие машины — во время профилактики.
1. Да
2. Никакого, не очень даже понимаю зачем они нам были бы нужны :)
3. У нас свой протокол и rpc. Бинарный поверх tcp/ip.
4. Не специалист в j2ee, не подскажу.
Нельзя, и что? Других игр полно. Что вам мешает играть в ВОВ? То что вы хотите поиграть именно в эту игру? Но ведь Mail.ru не просто так выкупает и творит что хочет. Вся локализация и оперирования всегда происходят в сотрудничестве с разработчиком игры.
Поэтому, то что делает с игрой мэил в России это то, что хочет разработчик, это и есть игра. Мэил не ломает игру донатом, монетизация в игре всегда такая, которая устраивает разработчка.
Есть такое радио: «Эхо Москвы». Если кто-то наезжает на Эхо, советует Венедиктову что крутить по радио, а что нет, он всегда отвечает одно и то же. «Переключайся на Авто Радио». Ну если вам что-то не нравится — просто переключитесь. Зачем петиции писать? Вас же никто не заставляет играть в АА, есть сотни других игр?
Для обычных серверов у нас есть метрика, называемая «нагрузка», которая включает в себя всё. :)
С базой чуть сложнее.
Мы смотрим
— сколько всего датабазных транзакций у нас прошло единицу времени.
— разбивка по типам. т.е. 100 операций взять предмет, 12 операций завершить квест и т.п.
— логируем, но не очень смотрим, мин/макс/среднее время отклика по одному типу транзакции за каждые 3 секунды. Это инфа для дебага а не для ежедневного просмотра.
— загрузку сервера исполнения транзакций в % от максимальной. Т.е. процент времени, который сервис тратит на обработку запросов.
— раз в несколько месяцев запускаем нагрузочный тест с логированием sql-я и потом, через pgfouine, находим и вычищаем топ тормозящих запросов.
Если кто-то подправил запрос и он стал тяжёлым, то мы увидим что нагрузка на датабазный сервис поднялась. Если кто-то сделал слишком частый запрос — мы увидим ненормальное количество операций определённого типа. Если кто-то написал медленный запрос, который выполняется редко, мы отловим это по профайлингу SQL-я.
Про In-Memory Data Grids. Мы не пробовали, для нас это оверкил пожалуй. Для надёжности нужно много серваков и в разных датацентрах. При большом желании мы сами бы смогли это сконфигурить, но игру потом всё равно придётся отдать зарубежным партнёрам, и они будут её разворачивать сами и на своём железе. Любая сложная схема будет уязвима для человеческого фактора. Самое ближайшее, на что я поглядывал, это MemSQL, но… хочется обойтись бесплатным софтом.
Впринципе, если PostgreSQL нам не хватит, я бы начал смотреть в сторону Тарантула. Во первых он наш, а во вторых его однотредовая архитектура нам ближе :)
Про партиции — базы и гейм механики это разные серваки и скалируются по разному. Как бы мы не масштабировали базу, механикам это не поможет. В целом, у нас нет потребности держать на одной карте больше народу, чем мы умеем сейчас. Нам просто не надо решать ту проблему, о которой вы говорите :)
Обычный юзкейс — в час ночи сгорает материнка или тот же БП.
БП и прочие подпорки это всё сложно и ненадёжно. Всегда найдётся тот, кто забудет что-то подключить/закупить и поднастроить. Я бы не рисковал без крайней нужды.
10 часов это очень мало. Можно не успеть, если учесть что ночь, админы спят, сервера стоят в датацентре, и надо туда доехать, надо вспомнить какой где сервер, вспомнить что данные надо куда-то там перелить, найти пустой диск, вставить его в новую тачку, перекопировать всё и т.д.
Во первых — а зачем? SSD достаточно быстр для нас.
Во вторых — Что-то как-то стрёмно :)
Итак, время жизни данных в i-RAM (при полностью заряженном аккумуляторе) для одного установленного модуля памяти исчисляется 24-32 часами, для двух модулей — 18-29 часов, а для 4 модулей — 12,6-24 часа в зависимости от типа модуля. То есть, более или менее уверенным в сохранности данных в i-RAM можно быть только в течение примерно 10-12 часов, если абстрагироваться от типа используемых модулей.
Про 32 бита всё понятно, а вот на на 64 битной архитектуру про 8GB заявлять без понимания суть вопроса это как-то странно.
rhaas.blogspot.ru/2012/03/tuning-sharedbuffers-and-walbuffers.html
Если не будет успевать, можно сделать его более злым, можно раскладывать наши базы на большее количество инстансов постгреса, чтобы счётчики транзакций набивались медленнее.
Решардинг в смысле перемещения шардов на другие машины — во время профилактики.
2. Никакого, не очень даже понимаю зачем они нам были бы нужны :)
3. У нас свой протокол и rpc. Бинарный поверх tcp/ip.
4. Не специалист в j2ee, не подскажу.
Я скорее про то, что голосовать рублём это самый надёжный способ достучаться до капиталистических акул.
Поэтому, то что делает с игрой мэил в России это то, что хочет разработчик, это и есть игра. Мэил не ломает игру донатом, монетизация в игре всегда такая, которая устраивает разработчка.
С базой чуть сложнее.
Мы смотрим
— сколько всего датабазных транзакций у нас прошло единицу времени.
— разбивка по типам. т.е. 100 операций взять предмет, 12 операций завершить квест и т.п.
— логируем, но не очень смотрим, мин/макс/среднее время отклика по одному типу транзакции за каждые 3 секунды. Это инфа для дебага а не для ежедневного просмотра.
— загрузку сервера исполнения транзакций в % от максимальной. Т.е. процент времени, который сервис тратит на обработку запросов.
— раз в несколько месяцев запускаем нагрузочный тест с логированием sql-я и потом, через pgfouine, находим и вычищаем топ тормозящих запросов.
Если кто-то подправил запрос и он стал тяжёлым, то мы увидим что нагрузка на датабазный сервис поднялась. Если кто-то сделал слишком частый запрос — мы увидим ненормальное количество операций определённого типа. Если кто-то написал медленный запрос, который выполняется редко, мы отловим это по профайлингу SQL-я.
Примерно так
Если мы один филд хотим разложить в 2 поля: json + поле для индексирования, можно использовать композитный тип.
p.s. код писал без IDE, наверняка не скомпилится.
Тут подробнее
dustin.sallings.org/2010/06/29/memcached-vbuckets.html
Впринципе, если PostgreSQL нам не хватит, я бы начал смотреть в сторону Тарантула. Во первых он наш, а во вторых его однотредовая архитектура нам ближе :)
Про партиции — базы и гейм механики это разные серваки и скалируются по разному. Как бы мы не масштабировали базу, механикам это не поможет. В целом, у нас нет потребности держать на одной карте больше народу, чем мы умеем сейчас. Нам просто не надо решать ту проблему, о которой вы говорите :)
БП и прочие подпорки это всё сложно и ненадёжно. Всегда найдётся тот, кто забудет что-то подключить/закупить и поднастроить. Я бы не рисковал без крайней нужды.
Во вторых — Что-то как-то стрёмно :)
corp.mail.ru/career/vacancies?dir=0&spec=0&prj=349&city=0