Это - текущее решение. от ораклы ожидается исправление бага с их новым суперсервером.
тем более, что для аконади совершенно не нужно этого монстрообразного продукта, а вполне достаточно nosql
Это не баг, это халтура - поленились конфиг довести до ума. Естественно, что современная СУБД с продакшн конфигом будет кушать. Поможет уменьшение размеров буферов и max_connections (куда их 256 вообще поставили??). Например.
Взять ту же MongoDB (noSQL), версия 3.2 у меня в продакшене сразу скушала 8.4 Гб оперативки в resident size, но в данном случае грех жаловаться, ибо она на пиках не напрягаясь обрабатывает по 1200+ запросов в секунду на 200 Гб-тной базе и по сравнению с предыдущими версиями выполняет сжатие "на лету" и намного меньше бьет по дискам.
При первом запуске он отобрал 1.5 гб. Но при последующих совсем немного. Интересно, а это решение вместо исправления бага? ツ
Это - текущее решение. от ораклы ожидается исправление бага с их новым суперсервером.
тем более, что для аконади совершенно не нужно этого монстрообразного продукта, а вполне достаточно nosql
Сейчас ~140мб. Это много?
нет.
Кот, тебе охота поговорить?
Иди на ссылки и там задавай вопросы, заодно и язык подучишь, будет хоть какая то польза...
Извините, что испортил вам тему своим присутствием. Больше меня здесь не будет…
Это не баг, это халтура - поленились конфиг довести до ума. Естественно, что современная СУБД с продакшн конфигом будет кушать. Поможет уменьшение размеров буферов и max_connections (куда их 256 вообще поставили??). Например.
Взять ту же MongoDB (noSQL), версия 3.2 у меня в продакшене сразу скушала 8.4 Гб оперативки в resident size, но в данном случае грех жаловаться, ибо она на пиках не напрягаясь обрабатывает по 1200+ запросов в секунду на 200 Гб-тной базе и по сравнению с предыдущими версиями выполняет сжатие "на лету" и намного меньше бьет по дискам.
Это - именно БАГ.
Ибо продукть этого класса от ораклы - это всегда баг.
Продукт = баг? Это админский юмор такой?
Отправить комментарий