Opened 4 weeks ago

Last modified 9 days ago

#13905 assigned Feature/Enhancement Request

Request to move a directory to SSD

Reported by: Owned by:
Priority: Medium Component: Tech
Keywords: Cc: jeff@…,
Sensitive: no


We are seeing some sluggish load times on our site during testing and want to see whether moving the static site assets to an SSD will help with page loads. The directory in question is /var/www/staging/pub and the current size is a bit over 5G. If we could have 10G allocated on the SSD for this directory, then we can see whether this makes a difference. If it does not lead to a clear improvement, we can revert this to free up that SSD space.

Note that the following subdirectory is already on a separate partition and we want to keep it that way (see ticket #13329 for details):

It is fine to reboot the server in order to deal with this request. Thanks.

Change History (9)

comment:1 Changed 4 weeks ago by

  • Cc added
  • Owner set to
  • Status changed from new to assigned

Hi, sorry for the delay. Yeah we've had issues today with another server on the same physical host that also has access to SSD drives. I think this is a worthwhile experiment although the virtual drive based on the SSD drive on your vm was not set up as a volume group for logical volumes so expanding space and adding another partition there would be less flexible going forward. I think we can add another virtual disk for now instead, however I think we should consider the possibility of turning one single virtual drive based on SSD into a vg source. Copying jamie here who opted against this initially when we set up the SSD backed partitions for mysql because of the extra layers of abstraction this would add.

comment:2 Changed 4 weeks ago by

Ok your proposed changes have been implemented. There is a new virtual drive based on SSD that appears as /dev/sdb that has already been formatted and is mounted as /var/www/staging/pub after copying the corresponding files to it.

while I think your problems yesterday were largely the result of issues with another virtual guest I am curious to see what changes in behaviour you observe now with static files backed by an SSD as well.

comment:3 Changed 4 weeks ago by

Thanks. Page loads do seem a bit faster now, and we will keep an eye on it this week and the server gets more use. If it looks like the SSD is not making a big difference I will let you know so we can free up that space, but for now it looks like it is helping.

comment:4 Changed 3 weeks ago by

Glad it is working better. Another thought if you are still seeing disk i/o related issues - if the runtime directory is producing a lot of cache files that could be a cause of the slow down. If these really are cache files that do not need permanent storage, mounting that partition as a tmpfs could dramatically speed things up. We tend to have more RAM that disk i/o on our physical servers, so if that would require a boost to RAM it would be worth it.

comment:5 Changed 3 weeks ago by

That's a good suggestion. The true cache files are in /var/www/staging/var/cache. Pretty sure that could be tmpfs. I will try that and see if we need to boost the RAM.

comment:6 Changed 2 weeks ago by

I'm also curious about how the tmpfs solution works out. Thinking about this long term in theory SSD disks space should be cheaper than RAM.

comment:7 Changed 9 days ago by

Using tmpfs for cache has helped with performance. Since implementing it, we have encountered a few out of memory errors, however. Can you please increment the RAM allotted to us and we'll see if that problem goes away?

comment:8 Changed 9 days ago by

Sure, this will require a server reboot. Do you want me to go ahead with this now?

comment:9 Changed 9 days ago by

Yes, please. It is fine to reboot the server.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.