Тем временем мы переехали на memcached. Redis остался только для персистентных очередей сайдкика.
Это означает, что каждую из следующих 86400 секунд будет становиться все лучше и лучше. ‎- псы в рапиде
Так, за последние 12 часов newrelic рапортует 374 мс. 95%-ответа. посмотрим через сутки. ‎- псы в рапиде
2226 LOC, ээээ. ‎- псы в рапиде
опа как. приготовить редис оказалось сложнее чем чем отказаться от его функционала? ‎- мёртвые не щадили меня
я его пытался использовать как LRU-cache. А он, я так понимаю, персистил все ключи, потому что у них была экспирация на сутки. Плюс сначала мы ему не прописали max-memory, и он жрал и дох (когда несколько дней пятисотило). Потом мы ему не прописали eviction policy, он еще подох (на фоне проапгрейженного MySQL). Ну и естественно при персистинге он жрет disk i/o. Короче, в memcached всех этих проблем автоматически нет. ‎- псы в рапиде
переход с редиса на memcached занял примерно 15-20 минут. ‎- псы в рапиде
"кто, кто все это будет делать!" (ц) белки-истерички ‎- Я много страдала
слушай, ну реально же — неизвестно, как эта штука будет себя вести под нагрузкой. с одной стороны, у меня там еще навалом вещей, которые можно и нужно оптимизировать. с другой стороны — ну претензии к рельсам же совершенно реальны. с третьей стороны — у нас сейчас на сервере 2Gb памяти при том, что на ноутбуке у меня 16Gb. То есть если тупо башлять $80/месяц, то вся эта ботвень будет жить в памяти. ‎- псы в рапиде
Так как мы не знаем, на каком сервере живет Фрифид (знаем только, что он "толстый", и на него уходит вроде как дофига бабла в месяц), то мы можем только догадываться. Также мы не знаем размер базы. Я подозреваю, что редис конечно себя должен вести грустно — тебе надо все держать в памяти с overflow в своп и при этом еще персистить на диск, причем довольно жестко. ‎- псы в рапиде
я примерно знаю, что сделать, чтобы почти линейно масштабировать Мокум по чтению. Я примерно представляю себе, что сделать, чтобы линейно масштабировать его по записи (пресловутый мастер-мастер). При необходимости. ‎- псы в рапиде
Алексей, ты всё правильно делаешь, но напоминаю мою реплику про то, что у меня есть не только домен, но и ресурс ‎- Щенок горящего борделя
Паша, мы поговорим об этом позже! Pain is necessary for good engineering. В противном случае ты не знаешь, что ты делаешь не так. Также, если бейслайниться от плохого случая, то хорошие случаи начинают работать еще лучше. ‎- псы в рапиде
я никогда не работал с рельсами, знаю лишь что местами они очень прожорливые. моя ремарка была про то, что есть разница между "попробовать технологию и выкинуть, если не подходит" и "защищать неподходящую технологию изо всех сил". мне нравится подход к разработке мокума. ‎- Я много страдала
Кстати, можно попробовать payload compression перед кэшем в качестве эксперимента, для всех кто длинее скажем 250 байт. Скримагер сжимается где то в полтора - два раза (проверил) CPU overhead достаточно маленький. ‎- туктуктук наноробот
а главное это делается с помощью добавления строчки compress: true в одно место :) ‎- псы в рапиде
overengineered magic, епта! ‎- псы в рапиде
@ayoshi "Скримагер сжимается где то в полтора - два раза" https://youtu.be/C2DwgxkOuw4?t=4m25s ? ‎- right wing hug squads
88% hit rate, eviction еще не начался, несмотря на 128Mb). ‎- псы в рапиде
@squadette ага. но трэйдоф все равно стоит померять. Там внутре нетривиальная неонка, и куча факторов связанных с тем что интерфейс к memcache не zero copy, дополнительный выигрыш на выделениях в слэбах, проигрыш на лишнюю копию выделенного объекта в сжатом виде который потом соберет сборщик мусора, и еще десяток мелких факторох. Вобщем, все равно должен быть выигрыш. С другой стороны: скажем одна запись в 80% до 1к, 128000 записей, я не знаю какой allocation overhead ( даже х4 для 4к блоков ) это все равно меньше 512МВ. Я сомневаюсь, что во всех комбинациях записей за день наберется 128000 записей. То есть slab allocation это потенциально единственный выигрыш. ‎- туктуктук наноробот
Зачем же оно так видимо притормаживает при нажатии на всего лишь Like? ‎- berkus
(бытует мнение, что сайдкик провоцирует утечки памяти на длинных дистанциях и особенно на долгих задачах. а вот рескью, в отличие от сайдкика, прибивает процессы по окончанию выполнению задачи и, соответственно, утеечки памяти не успевают достичь значимых размеров. при частых деплоях и рестартах сервисов приложения, утечки с сайдкиком тоже обычно не видны.) ‎- stepashka
(Sounds like a myth)! ‎- blackout drunk
@berkus, потому что сейчас на сервере 700 Мб. свопа, большую часть которого занимает MySQL. Мы щас дочитаем доку, и научимся ограничивать его аппетиты. А сколько кстати памяти на сервере с Фрифидом? И насколько она занята? Сколько Redis жрет? Спасибо! ‎- псы в рапиде
@stepashka, вся рубевая часть едет совершенно стабильно, практически два-три скачка в день (ну, кроме деплоев, естественно). То есть да, Руби жрет около 700 Мб — но строго не больше. ‎- псы в рапиде
@stepashka в силу того, что у меня в оффлайне выполняются не скрипты, а достаточно простые рубевые процедуры — я скорее даже за то, чтобы состояние среды исполнения не выбрасывалось после изменений. Я не вижу проблем с сайдкиком. ‎- псы в рапиде
Eviction во все поля, hit rate 89%, редис упал до 37Mb. На сервере 500 Mb свободной памяти и столько же свопа. Видимо, мускуль угнал какую-то ерунду в своп и сидит там спокойно. ‎- псы в рапиде
^ он это любит в новых версиях ‎- мёртвые не щадили меня
@squadette А почему он вообще что то угоняет в своп? Каков размер ДБ файлов? Что вот тут: sysctl vm.swappiness ? ‎- туктуктук наноробот
@ayoshi это хорошо что ос угоняет takoe в своп, нефиг ненужным мусором память занимать. проблема тут в том, что как-то ограничить ему занимаемую память - нельзя, а понять на что он её аллоцирует и зачем - это такая особая магия, местами совершенно неочевидная. ‎- мёртвые не щадили меня
@ayoshi: vm.swappiness=10; размер ДБ-файлов: 2.4Gb. mysqld имеет 2468136 VIRT и 615304 RES по топу. ‎- псы в рапиде
VIRT понятно, поскольку mysql использует mmap() на дб файлы, к сожалению нет никакого способа ему сказать что сносить в своп. Вообще, если есть память я бы сбросил vm.swappiness в 1, (0 приводит к ошибкам в некоторых версиях ядра (3.5, не помню еще в каких) ‎- туктуктук наноробот
Практически весь своп — это mysql: PID=28053 swapped 425440 KB (mysqld) ‎- псы в рапиде
Подозреваю, @berkus имел в виду тормоза, связанные с тем, что после отправки лайка делается редирект с отображением перестроенной этим лайком ленты. Это поведение, как я понимаю, будет в будущем исправлено, а с optimistic updates этим операциям можно будет сделать практически нулевую latency. ‎- slider23
@squadette а вещи первого уровня очевидности вроде аллоцируемой на старте памяти для performance_schema исключили? show engine performance_schema status там часом эти 400 мегов из свопа не показывает? ‎- мёртвые не щадили меня
@ayoshi, у меня нет вещей первого уровня очевидности, потому что я нихуя не умею администрировать MySQL — я знаю только, что если у меня будут проблемы — то я найду неограниченное количество экспертизы. Поэтому спасибо! щас я посмотрю в этот мистический запрос! ‎- псы в рапиде
Извините, что лезу с идиотскими советами, но может быть, 59 евро в месяц в Хетцнер - и 32 GB RAM закрывают проблему (https://www.hetzner.de/de/hosting/produkte_rootserver/ex40ssd)? Немного смущают дискуссии высокооплачиваемых европейских специалистов про 400 мегов свопа в 2015 году. Нет, я понимаю потенциальные возражения, что это инженерный вопрос, постойте-ка, давайте разберёмся, но... :-) ‎- igors
igors, ну сервису сегодня ровно месяц. если сейчас это 32GB и 59 евро, то через полгода это будет 128Gb и сколько там евро-то. то есть да, вопрос инженерный и лучше его порешать пораньше ‎- right wing hug squads
128 GB это 139 евро (https://www.hetzner.de/de/hosting/produkte_rootserver/px121ssd). Жестокая правда в том, что проблема не скалируется линейно, т. е. в тех 128 GB скорее всего будет уже другая ситуация. ‎- igors
@igors, я это писал вчера Мотто, не могу найти где. Повторю. Я считаю, что pain is necessary for good engineering. Я хочу отбейслайниться от плохого случая, чтобы хорошо обрабатывать хорошие. ‎- псы в рапиде
@igors, ну во-первых ^, а во-вторых 139 в месяц -- это 1668 в год, внезапно уже дороговато для хобби ‎- right wing hug squads
У меня негативный опыт с редисом. 1) Требовательность к памяти. В документации пишут, что при записи rdb они так нежно форкают, что дополнительной памяти не надо - и это неправда. Чтобы всё комфортно работало, памяти надо *2 к размеру базы. 2) На больших объёмах базы резко возрастает latency при выводе rdb и в целом через механизм master/slave. В одной доброй организации мы сейчас переезжаем с редиса на аэроспайк. ‎- igors
Гг, а мои кореша из одной московской компании, перееззжают с аэроспайка на редис. Потому как первый данные проёбывал. ‎- адский хардлайн в засаде
Wow, а есть подробности? User error точно нет? Пытались это решать с поддержкой? (Стартапам дают какой-то бесплатный период на подписку Enterprise.) ‎- igors
@igors (копирую из чатика с @larhat :)) 1. Оно не умеет релоадить конфигурацию. Т.е. вот ты изменяешь размер памяти скажем выделенной. или неймспейс добавляешь. и ты должен прорестартить весь кластер. При том сначала вырубив полностью, т.е. с даунтаймом. Интерпрайз этого не изменяет. 2. В том числе увеличивает пиздец первого. оно не умеет фаст рестартов, т.е. при рестарте оно читает все данные сначала, а потом начинает работать. В платной версии оно умеет фаст рестарты, НО не фаст рестарты секондари индексов. Перестройка индексов у меня занимала сутки. Что означает, что при рестарте кластера (изменение конфигов, выключилось электричество, развалился кластер) подниматься он будет 24 часа!!11, что равносильно даунтайму сервиса на сутки (ваш бизнес это выдержит?) 3. У меня почему-то (хз почему, сеть моргала мб) разваливался кластер. И не собирался обратно. Судя по логам оно пыталось приконнектится к ноде, которая была задана как join нода при старте ноды. При том этой ноды уже давно не было (она существовала на момент старта, но потом была убита). Ну т.е. пиздец, оно не сохраняет нигде состояние кластера по мере жизни. 4. После того как я пришел, и изменил mesh ноды, оно поднялось, но количество объектов которые оно хранит по статам уменьшилось с 120 млн до 90 млн :) ну и секондари индексы не работали еще сутки :) ‎- prepor
@igors 5. При потреблении КПУ на уровне 10 процентов, запуск scan-lua-жоба приводил к увеличению латенси в 2 раза (1мс до 2мс). Ок. Но через 10 часов работы ВНЕЗАПНО начинало жрать кпу, LA до 14, латенси до 200мс, сервис падает (а уже все спят, конечно). Совсем не понятно почему. Абсолютно повторяемое поведение было. Я как бэ не эксперт, если кто-то расскажет, что я долб и не секу — будет круто. ‎- prepor
Андрей, привет! "Aerospike the Only Visionary Database in the 2014 Gartner MQ" ‎- псы в рапиде
Ужасно. Про монгу я в какой-то момент на сисадминском вики одной корпорации повесил неоновую рекламу "REPAIR MONGO 24 HOURS", потому что все ресурсы были, действительно, заняты поочерёдными репейрами монг у десятков клиентов. Говорят, что сейчас стало лучше. ‎- igors
@igors кроме того вот, например линк на куда более обстоятельное исследование, куда более авторитетного парня https://aphyr.com/posts/324-call-me-maybe-aerospike. Это про отношение аэроспайка к консистентности и проебу данных. @squadette, привет! ‎- prepor
^ чувак который написал Jepsen — охуенен. ‎- псы в рапиде
^^ воу! спасибо за бложек ‎- BSOD bluez
Спасибо. Невиданное дело происходит на мокуме - социалочка, а приносит пользу! ‎- igors

2015-2016 Mokum.place