Web/Yum/Deb node running ouf space

I just noticed that web002 is 100% full on /var/www. I managed to manually
clear up some debs from freightstage to make enough space to run the
freightstage cleanup cronjob manually - that left about 1.7Gb free at 5pm).
That's not likely to last long though.

The debs are far larger than the rpms - perhaps we should more aggressively
prune the staging debs?

Greg

This will apparently be fixed tomorrow during the scheduled maintenance -
until then, it's a possible explanation for any rsync failures you may see.

I'm planning to expand the volume today during the maintenance period,
but it needed an fsck first. I didn't think it worthwhile to try and
keep even fewer packages, as the cleanup is already reasonably aggressive.

I do expect the disk usage to increase over time because of continuing
releases, I think it's just got to the stage where more disk's required.

··· On 13/04/16 17:53, Greg Sutcliffe wrote: > I just noticed that web002 is 100% full on /var/www. I managed to > manually clear up some debs from freightstage to make enough space to > run the freightstage cleanup cronjob manually - that left about 1.7Gb > free at 5pm). That's not likely to last long though. > > The debs are far larger than the rpms - perhaps we should more > aggressively prune the staging debs?


Dominic Cleal
dominic@cleal.org

All done, fscked and extended the filesystem by another 20GB. There's a
further 20GB available in the VG still, and we'll be able to resize
online from now on (the problem before was that the ext4 fs had an error
marker).

Beyond that we'll need to create a new, larger block storage device as
it can't be resized.

··· On 14/04/16 08:04, Dominic Cleal wrote: > On 13/04/16 17:53, Greg Sutcliffe wrote: >> I just noticed that web002 is 100% full on /var/www. I managed to >> manually clear up some debs from freightstage to make enough space to >> run the freightstage cleanup cronjob manually - that left about 1.7Gb >> free at 5pm). That's not likely to last long though. >> >> The debs are far larger than the rpms - perhaps we should more >> aggressively prune the staging debs? > > I'm planning to expand the volume today during the maintenance period, > but it needed an fsck first.


Dominic Cleal
dominic@cleal.org

Good stuff. I agree with not pruning further, I wasn't sure what capacity
we had left. Another 20Gb should do for a good while, that's 50% of the
current deb+stagingdeb size.

Thanks!