Production postmortemThe case of the intransigent new database

time to read 3 min | 480 words

A customer called us to tell that they had a problem with RavenDB. As part of their process for handling new customers, they would create a new database, setup indexes, and then direct all the queries for that customer to that database.

Unfortunately, this system that has worked so well in development died a horrible death in production. But, and this was strange, only for new customers, and only in the create new customer stage. The problem was:

  • The user would create a new database in RavenDB. This just create a db record, and its location on disk. It doesn’t actually initialize a database.
  • On the first request, we initialize the db, creating it if needed. The first request will wait until this happens, then proceed.
  • On their production systems, that first request (which they used to create the indexes they require) would time out with an error.

Somehow, the creation of a new database would take way too long.

The first thought we had was they are creating the database on a path of an already existing database, maybe a big one that had a long initialization period, or maybe one that required recovery. But the customer validated that they were creating the database on an empty folder.

We looked at the logs, and the logs just showed a bunch of time were there was no activity. In fact, we had a single method call to open the database that took over 15 seconds to run. Except that on a new database, this method just create a bunch of files to start things out and is ready really quickly.

That is the point that led us to suspect that the issue was environmental. Luckily, as the result of many such calls, RavenDB comes with a pretty basic I/O Test tool. I asked the customer to run this on their production system, and I got the following:image

And now everything was clear. They were running on an I/O constrained system (a cloud machine), and they were running into an interesting problem. When RavenDB creates a database, it pre-allocate some files for its transactional journal.

Those files are 64MB in size, and the total write for a new Esent RavenDB database with default configuration is just over 65MB. If your write throughput is less than 1MB/sec sustained, that will be problematic.

I let the customer know about the configuration option to take less space at startup (Esent RavenDB databases can go as low as 5MB, Voron RavenDB starts at 256Kb), but I also gave them a hearty recommendation to make sure that their I/O rates improved, because this isn’t going to be the only case where slow I/O will kill them.

More posts in "Production postmortem" series:

  1. (22 Feb 2018) The unavailable Linux server
  2. (06 Dec 2017) data corruption, a view from INSIDE the sausage
  3. (01 Dec 2017) The random high CPU
  4. (07 Aug 2017) 30% boost with a single line change
  5. (04 Aug 2017) The case of 99.99% percentile
  6. (02 Aug 2017) The lightly loaded trashing server
  7. (23 Aug 2016) The insidious cost of managed memory
  8. (05 Feb 2016) A null reference in our abstraction
  9. (27 Jan 2016) The Razor Suicide
  10. (13 Nov 2015) The case of the “it is slow on that machine (only)”
  11. (21 Oct 2015) The case of the slow index rebuild
  12. (22 Sep 2015) The case of the Unicode Poo
  13. (03 Sep 2015) The industry at large
  14. (01 Sep 2015) The case of the lying configuration file
  15. (31 Aug 2015) The case of the memory eater and high load
  16. (14 Aug 2015) The case of the man in the middle
  17. (05 Aug 2015) Reading the errors
  18. (29 Jul 2015) The evil licensing code
  19. (23 Jul 2015) The case of the native memory leak
  20. (16 Jul 2015) The case of the intransigent new database
  21. (13 Jul 2015) The case of the hung over server
  22. (09 Jul 2015) The case of the infected cluster