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

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)
}


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

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

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

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

Если создать новую коллекцию и записывать в нее, то все работает как надо.
Записывается примерно по 300 документов в секунду.
Отключите ожидание результата, или пишите в параллель. У меня на ноутбуке примерно 10к в сек пишет в пустую коллекцию.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@alexxandr
you'll see in memory only 0xDEADFACE
удалите хипстерскую лажу и используйте нормальные БД
Ответ написан
Комментировать
dimonchik2013
@dimonchik2013
non progredi est regredi
чудес не бывает:
с заполнением SSD скорость записи уменьшается - trim процессору приходится соображать, куда писать, чтобы не поверх вписанного но не стертого

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы