Или такое https://lastbackend.com

я сравнивал bcache, flashcache и l2arc из zfs. беда в том, что у всех кроме bcache на random read получаются дичайшие провалы по hit ratio.

когда у вас hit ratio прыгает между 87% и 21-23% - это говно а не кеш.

про jenkins говорили - оно же везде тащит свой jar которому нужно java - и это предлагается для pipeline ... а то что весь гуй только размазывает задачи, а то что потом боятся обновить, вдруг плагины сломаются, а плагины которые по пять лет стаус не меняют с багфиксами которые годами закрываются...

а потом когда кеш кончается начинается reclaim и наступает шоу.

в общем jenkins где-то в прошлом застрял.

@gorazio спасибо, очень похоже

хотя нет

это ведь те, кого купил докер

а потом когда кеш кончается начинается reclaim и наступает шоу.

Как на random read кеш вообще может помочь?

а как может тип кеша влиять на хит ратио? если ты уже спрашивал эти данные, то хит будет, а если нет, то нет

это сервис, а мне нужно на своем сервере поднять

кто их за тебя спросит-то

хочешь хитратио прогрей кеш

Как на random read кеш вообще может помочь?

элементарно же: каждую итерацию порядок чтения блоков тот же

bcache ещё хочет весь накопитель (блочное устройство), dm-cache (lvm-cache) не требует

хочешь хитратио прогрей кеш

грел, ясен пень.

почему у тебя нет хитратио тогда?)

bcache ещё хочет весь накопитель (блочное устройство), dm-cache (lvm-cache) не требует

с чего это вдруг?

bcache ещё хочет весь накопитель (блочное устройство), dm-cache (lvm-cache) не требует

не, ему все равно

почему у тебя нет хитратио тогда?)

так я и говорю, что тащат в кеш лишнее и оно вымывает нужное

элементарно же: каждую итерацию порядок чтения блоков тот же

Стоп, если запрашивать случайные данные и размер кеша значительно меньше общего их объёма - старые записи просто рано или поздно будут вымываться, и хита вообще никогда не будет. Или я не совсем понимаю ваш паттерн использования кеша.

Стоп, если запрашивать случайные данные и размер кеша значительно меньше общего их объёма - старые записи просто рано или поздно будут вымываться, и хита вообще никогда не будет. Или я не совсем понимаю ваш паттерн использования кеша.

ну смотри: у тебя на диске лежит развесистое дерево, в листиках - файлы. так вот, банальный find по всему дереву - это будет random read.

это сервис, а мне нужно на своем сервере поднять

Kitematic вроде оно

Емнип, это дерево ядро должно в оперативке кешировать. Оно не такое большое.

Емнип, это дерево ядро должно в оперативке кешировать. Оно не такое большое.

нуну. dentry cache на 16Гб видел? а плюс ещё inode cache

можно slabtop запустить и удивиться.

Ну все зависит от объёма памяти, конечно

на таком дереве на зфс файнд займет неделю)

Стоп, если запрашивать случайные данные и размер кеша значительно меньше общего их объёма - старые записи просто рано или поздно будут вымываться, и хита вообще никогда не будет. Или я не совсем понимаю ваш паттерн использования кеша.

представь, что у тебя есть набор файлов(миллионы) и для каждого файла есть список оффсетов. процесс открывает файл, бежит по списку и прыгает по файлу(ессно читая некое количество байт).

не, ему все равно

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

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

я думал это кеш надо цеплять к разделу, а не раздел к кешу)

ну с какой стороны посмотреть ))

там можно один кеш к нескольким разделам прицепить если очень хочется

но при этом же придётся fs пересоздать, предварительно данные существующие убрать и положить обратно

Стоп, если запрашивать случайные данные и размер кеша значительно меньше общего их объёма - старые записи просто рано или поздно будут вымываться, и хита вообще никогда не будет. Или я не совсем понимаю ваш паттерн использования кеша.

короче, у нас объемы реально читаемого сильно меньше хранимого.

короче, у нас объемы реально читаемого сильно меньше хранимого.

Тогда да, действительно будет профит

ну если мой бкеш ломается на wb, то вас это не коснется я думаю

но то что у вас не хватает озу и ссд под ваш специфичный ворклоад не повод называть остальное гавном:)

но то что у вас не хватает озу и ссд под ваш специфичный ворклоад не повод называть остальное гавном:)

Я к тому что эвристика на seq read у bcache самая крутая

А с wb там же куча крутилок gc есть

вот kitematic отличный пример удобного интерфейса управления докер контейнерами

чтобы такое же, но для веба на одном серваке?

Ааа, я неправильно понял что ты хочешь.

чтобы такое же, но для веба на одном серваке?

Shipyard? Rancher?

подскажите, где хостить персональные данные? всякие платежные, карточек там

я провайдеров то нашел, пачку целую, но как выбрать?

я провайдеров то нашел, пачку целую, но как выбрать?

Cloud-pro.ru

Cloud-pro.ru

так это просто облако?

Кто-нибудь пробовал?

Новый модный Web UI для Jenkins: https://jenkins.io/blog/2016/05/26/introducing-blue-ocean/

его руками пока надо собирать, дождусь плагина

друзья сайто-мастера, скажите, https://radiopolarniki.spb.ru/ - быстро работает? и если нет - будет круто узнать почему :)

вроде норм

друзья сайто-мастера, скажите, https://radiopolarniki.spb.ru/ - быстро работает? и если нет - будет круто узнать почему :)

CDN и кеш заюзаны?

Довольно быстро грузится, но на генерацию страницы уходит 50мс. =\ Либо это пинг, либо можно упороться до 10-15 мс. закешировать

Довольно быстро грузится, но на генерацию страницы уходит 50мс. =\ Либо это пинг, либо можно упороться до 10-15 мс. закешировать

гг

CDN нету

либо картинки лежат в жопе

у нас так есть кое где

кеш должен быть :)

Довольно быстро грузится, но на генерацию страницы уходит 50мс. =\ Либо это пинг, либо можно упороться до 10-15 мс. закешировать

super-duper-cache не юзал

там стоит nginx+php-fpm

он работает в независимости от

Вообще и рендер быстрый и загрузка, но фактически пользователю страница показывается через 3с где-то (на моем компе), что довольно много. Я бы сделал плавную отрисовку вниз, вместо прогрессбара.

если в конфигах не пакостить

https://wordpress.org/plugins/wp-super-cache/

https://wordpress.org/plugins/jetpack/

Я вижу что сайт более-менее статический, чего бы nginx кеш не впилить на 1-2 минуты?

Тогда генериться будет моментально

Вообще и рендер быстрый и загрузка, но фактически пользователю страница показывается через 3с где-то (на моем компе), что довольно много. Я бы сделал плавную отрисовку вниз, вместо прогрессбара.

а это js ?

не?

а это js ?

Ну да

ясн, надо js ковырять. сцук

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

Теоретически достаточно ее убрать.

Уж не знаю, для чего она понадобилась.

ну я не добавлял ))

и еще хер знает как убрать )