MongoDB. Почему при увеличении размера коллекции сильно увеличивается время вставки новых документов?

Question

[nexcode]

MongoDB 3.2.1 | wiredTiger

Вставляются новые документы.
Никаких условий или сложной выборки нет.

Collection statistics:

"count" : 149380522
"size" : 5582314593.0
"avgObjSize" : 37
"storageSize" : 12036964352.0
"capped" : false
"totalIndexSize" : 1537122304.0

/etc/security/limits.d/99-mongodb.conf

mongod          soft    fsize           unlimited
mongod          hard    fsize           unlimited
mongod          soft    cpu             unlimited
mongod          hard    cpu             unlimited
mongod          soft    as              unlimited
mongod          hard    as              unlimited
mongod          soft    nofile          65536
mongod          hard    nofile          65536
mongod          soft    nproc           65536
mongod          hard    nproc           65536

В выводе dmesg нет ничего бросающегося в глаза.

mongostat:

insert query update delete getmore command % dirty % used flushes vsize  res qr|qw ar|aw netIn netOut conn                      time
    *0    *0    217     *0       0   139|0     2.0   29.4       0  2.6G 2.3G   0|0   0|1  136k    59k    6 2016-02-15T14:45:49+03:00
    *0    *0    175     *0       0   109|0     0.7   29.4       1  2.6G 2.3G   0|0   0|1  108k    50k    6 2016-02-15T14:45:50+03:00
    *0    *0     43     *0       0    32|0     0.5   29.4       0  2.6G 2.3G   0|0   0|1   29k    27k    6 2016-02-15T14:45:51+03:00
    *0    *0     10     *0       0     7|0     0.6   29.4       0  2.6G 2.3G   0|0   0|1    6k    20k    6 2016-02-15T14:45:52+03:00
    *0    *0     28     *0       0    15|0     0.6   29.4       0  2.6G 2.3G   0|0   0|1   14k    23k    6 2016-02-15T14:45:53+03:00
    *0    *0      2     *0       0     1|0     0.6   29.4       0  2.6G 2.3G   0|0   0|1  425b    18k    6 2016-02-15T14:45:54+03:00
    *0    *0      1     *0       0     2|0     0.6   29.4       0  2.6G 2.3G   0|0   0|1  368b    18k    6 2016-02-15T14:45:55+03:00
    *0    *0     17     *0       0    14|0     0.6   29.5       0  2.6G 2.3G   0|0   0|1   11k    21k    6 2016-02-15T14:45:56+03:00
    *0    *0     11     *0       0    10|0     0.6   29.5       0  2.6G 2.3G   0|0   0|1    8k    20k    6 2016-02-15T14:45:57+03:00
    *0    *0      4     *0       0     2|0     0.6   29.5       0  2.6G 2.3G   0|0   0|1    2k    18k    6 2016-02-15T14:45:58+03:00

top:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2222 mongod    20   0 4200976 3,692g   6664 S   3,3 23,9   0:50.26 mongod

Сильные задержки на вставку начались примерно от 140 миллионов документов.
Если создать новую коллекцию и записывать в нее, то все работает как надо.
Записывается примерно по 300 документов в секунду.

Пример вставки документа (golang + labix.org/mgo):

if _, err := c.UpsertId(bson.ObjectIdHex("xxxxxxx"), bson.M{
	"$set": bson.M{"field": "string"},
}); err != nil {
	panic(err)
}

Собственно, как исправить данную проблему?

Comments

[lega]

Приведите пример запроса которым вставляете, ну и индексы

[pomeo]

sub документы случаем не используете?

[nexcode]

lega: Пример добавил. Индекс только один: "_id"

[nexcode]

Sergey Ovechkin: В общем - да, использую. Именно в этой коллекции - нет.

Answer 1

[lega]

Возможно резкое падение связано с системой кеширования в ОС, в начале данные загоняются в ram, далее они упираются в лимит и медленно сливаются на диск. Новая БД - новый файл - отдельный кеш блок... - работает быстро в начале.

Было бы интересно проверить на рам диске, что-б исключить тормоза io, если памяти много.

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

"avgObjSize" : 37

С таким объемом документа процент эффективной информации снижается. Для этой задачи можете попробовать LevelDB или его прототипы, в теории будет экономней и быстрее раз в 10.

Если создать новую коллекцию и записывать в нее, то все работает как надо.
Записывается примерно по 300 документов в секунду.

Отключите ожидание результата, или пишите в параллель. У меня на ноутбуке примерно 10к в сек пишет в пустую коллекцию.

Comments

[nexcode]

Посмотрели более подробно. Вроде как упирается в io.

Answer 2

[alexxandr]

удалите хипстерскую лажу и используйте нормальные БД

Answer 3

[Dimonchik]

чудес не бывает:
с заполнением SSD скорость записи уменьшается - trim процессору приходится соображать, куда писать, чтобы не поверх вписанного но не стертого

Монго так же при каждой вставке перестраивает индекс, даже если она его пачками/страницами выделяет - все равно ведь нужно знать, какой использован, какjй нет и оптимизировать структуру-то

кратко по оптимизации - тут

практические советы - тут и тут: ничего нового - делайте меньше индекс т.е. несколько коллекций вместо одной

можете утешиться, что скорость на вставку у Монги гораздо выше RDBMS

как побороть проблему? смотрите на очереди, смотрите на Aerospike

Comments

[nexcode]

Тогда вопрос, почему падение производительности столь резкое и столь заметное? Если бы мы наблюдали увеличение времени записи по мере роста коллекции - вопросов бы не было. А тут раз и резко просели.

[nexcode]

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

[Dimonchik]

ssd я привожу в пример безотносительно Mongo, общеизвестно, что в малообъемных ССД скорость меньше (иногда могут искусстенно), а в больше объемных - больше,но есть предел. При заполнении же скорость снижается потмому что контроллер уже не может писать без обратной связи: в любом курсе по алгоритмам расскажут, что при больших N возрастает зависимость от длины обрабатываемых данных.
Почему снизилась скачком - хз, опять же - хз как устроена структура данных внутри, может для кратковременных объемных она умеет, а для постоянных проявляются артефакты. Тут только синтетические тесты - новый винт, проц, те же объемы и разные настройки.