- Joined
- Nov 25, 2013
- Messages
- 7,776
Hi all,
my home FreeNAS runs two pools for data. One RAIDZ2 with four spinning disk drives and one mirror with two SSDs. Toying with InfluxDB and Grafana in the last couple of days I found that I seem to have a constant write load of 1 Megabyte (!) per second on the SSDs. What the ...?
So I run three VMs on the SSDs in total. One with Windows 10, two with Ubuntu running Confluence, A wiki essentially, with files for attachments and MySQL as the backend database. Clearly the writes had to stop when the wikis were not used at all, just sitting idle, right?
Well even with a full query log and quite some experience in the operation of web applications I could not figure out what Confluence is doing (productively, no doubt) but trust me, it writes a couple of hundred kbytes to the database each second just sitting idle.
So I moved the database server to a jail on my HDD pool, copied the databases, and reconfigured the two wikis, And the write load dropped. Significantly. But ...
Now I ran into startup problems. While in a single VM systemd can wait for the database to start up before firing up Confluence, now I have the wikis in two VMs and the DB in a jail. Which seems to start after the VMs in FreeNAS. Of course Confluence just complains and refuses to start instead of trying again after the next hit by some web browser like any stupid PHP application would. Oh well ... maybe an artificial systemd service that checks for the listening MySQL port ...
And then I saw the light and did the math.
1 Megabyte per second is huge, right? Well, not quite so it turns out. It sums up to 86.400 Megabytes per day. Lets make that 100 Gigs because I can never figure out if we are talking binary or decimal, and there may be additional write jobs when somebody is actually using the wiki, of all things.
The SSDs in question have a TBW of 600. That's 600 Terabytes of data written. And that's only the guaranteed volume, they won't break at 600 TB plus one byte. That or 5 years, Samsung says.
So that's 6.000 days of constant abuse or more than 16 years. They will long be replaced by half of that time.
So rollback to the "1 pm" snapshot, opt for easier management and simply don't worry about the writing. I do replicate the VM ZVOLs to my HDD pool, though.
Hope you enjoyed my story. I definitely learned something.
Kind regards,
Patrick
my home FreeNAS runs two pools for data. One RAIDZ2 with four spinning disk drives and one mirror with two SSDs. Toying with InfluxDB and Grafana in the last couple of days I found that I seem to have a constant write load of 1 Megabyte (!) per second on the SSDs. What the ...?
So I run three VMs on the SSDs in total. One with Windows 10, two with Ubuntu running Confluence, A wiki essentially, with files for attachments and MySQL as the backend database. Clearly the writes had to stop when the wikis were not used at all, just sitting idle, right?
Well even with a full query log and quite some experience in the operation of web applications I could not figure out what Confluence is doing (productively, no doubt) but trust me, it writes a couple of hundred kbytes to the database each second just sitting idle.
So I moved the database server to a jail on my HDD pool, copied the databases, and reconfigured the two wikis, And the write load dropped. Significantly. But ...
Now I ran into startup problems. While in a single VM systemd can wait for the database to start up before firing up Confluence, now I have the wikis in two VMs and the DB in a jail. Which seems to start after the VMs in FreeNAS. Of course Confluence just complains and refuses to start instead of trying again after the next hit by some web browser like any stupid PHP application would. Oh well ... maybe an artificial systemd service that checks for the listening MySQL port ...
And then I saw the light and did the math.
1 Megabyte per second is huge, right? Well, not quite so it turns out. It sums up to 86.400 Megabytes per day. Lets make that 100 Gigs because I can never figure out if we are talking binary or decimal, and there may be additional write jobs when somebody is actually using the wiki, of all things.
The SSDs in question have a TBW of 600. That's 600 Terabytes of data written. And that's only the guaranteed volume, they won't break at 600 TB plus one byte. That or 5 years, Samsung says.
So that's 6.000 days of constant abuse or more than 16 years. They will long be replaced by half of that time.
So rollback to the "1 pm" snapshot, opt for easier management and simply don't worry about the writing. I do replicate the VM ZVOLs to my HDD pool, though.
Hope you enjoyed my story. I definitely learned something.
Kind regards,
Patrick
Last edited:
