Несколько рекурсивных async_wait на повышение
В случае удаления большого фрагмента данных из коллекции, и коллекция никогда не использует удаленное пространство для новых документов, это пространство должно быть возвращено в операционную систему, чтобы оно могло использоваться другими базами данных или коллекциями.
Поведение процесса уплотнения зависит от механизма MongoDB следующим образом
db.runCommand({compact: collection-name })
MMAPv1
Операции дефрагментации операций уплотнения данных и amp; индексов. Однако он не освобождает место для операционной системы. Операция по-прежнему полезна для дефрагментации и создания более непрерывного пространства для повторного использования MongoDB. Тем не менее, это бесполезно, когда свободное место на диске очень мало.
Во время операции уплотнения требуется дополнительное пространство на диске до 2 ГБ.
Блокировка уровня базы данных
WiredTiger
Механизм WiredTiger обеспечивает сжатие по умолчанию, которое потребляет меньше места на диске, чем MMAPv1.
Компактный процесс освобождает свободное пространство к операционной системе. Для выполнения компактной операции требуется минимальное дисковое пространство. WiredTiger также блокирует все операции с базой данных, так как он нуждается в блокировке уровня базы данных.
Для механизма MMAPv1 компактность не возвращает пространство в операционную систему. Для освобождения неиспользуемого пространства вам потребуется выполнить операцию восстановления.
db.runCommand({repairDatabase: 1})
Здесь вы можете найти подробную информацию о компактной работе здесь
1 ответ
Кажется, что ответ для поведения лежит в документации для basic_waitable_timer::expires_at(const time_point & expiry_time) :
Эта функция устанавливает время истечения. Любые ожидающие асинхронные операции ожидания будут отменены. Обработчик для каждой отмененной операции будет вызываться с кодом ошибки boost :: asio :: error :: operation_aborted.
В вашем примере, когда заканчивается первый таймер, он вызывает
expires_at, чтобы переслать таймер на секунду. Однако это отменяет второй запущенный вызов await, который теперь будет вызываться непосредственно на следующей итерации цикла с ошибкойoperation_aborted. Однако, поскольку вы не проверяете код ошибкиec, вы этого не видите. Теперь этот обработчик будет снова напрямую пересылать таймер и тем самым отменять последнийasync_wait, который был запущен.Это продолжается до тех пор, пока обработчики не отменят себя достаточно часто, чтобы
count==0работал только один таймер. Поскольку дата истечения срока пересылается каждый раз по 1 с, код все еще ожидает истечения целых 40 с.