I have a linux box with a partition full, the partition being full is stopping SQL from being started. I Need to work out what files I need to delete in order to free up space on the partition, I have tried deleting backup database files from mysql by hand using rm, and deleting old log files, but this just frees up more space from sda8 - which has plenty of space. Does anyone know how to find out which files are in sda7?
Here is the output of df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 4.6G 1.2G 3.2G 27% /
tmpfs 1.8G 0 1.8G 0% /lib/init/rw
varrun 1.8G 92K 1.8G 1% /var/run
varlock 1.8G 0 1.8G 0% /var/lock
udev 1.8G 168K 1.8G 1% /dev
tmpfs 1.8G 0 1.8G 0% /dev/shm
lrm 1.8G 2.5M 1.8G 1% /lib/modules/2.6.28-19-generic/volatile
/dev/sda5 76M 20M 53M 27% /boot
/dev/sda8 220G 7.4G 202G 4% /home
/dev/sda7 4.6G 4.4G 0 100% /var
Thanks
/dev/sda7 4.6G 4.4G 0 100% /var
varrun 1.8G 92K 1.8G 1% /var/run
varlock 1.8G 0 1.8G 0% /var/lock
I re-arranged your df -h output a little and trimmed it to the most meaningful lines.
You need to remove content in /var/ that is not in /var/run or /var/lock. A very fast way to free up a giant pile of free space on Debian-derived systems (including Ubuntu) is to run apt-get autoclean -- this will remove old packages from /var/cache/apt/archives/. apt-get clean will free up even more space by removing all packages from that directory. (These packages are kept around for your troubleshooting.) If you're not sure which to run, apt-get clean is my suggestion -- you'll almost never need those packages anyway.
But that's not a long-term solution to your problem. You should probably store your SQL databases in /home instead. You have 202 gigabytes free there and you probably have a backup solution of some sort in place on your /home partition -- right? -- that you might not have thought to back up from /var/. Make a new directory in /home/ for your SQL databases, make it owned by the user and group accounts for your SQL server, move your databases, and configure the database server to use the new locations.
Related
I have a server running Centos 7. This is the result of df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.4G 0 7.4G 0% /dev
tmpfs 1.5G 139M 1.4G 10% /run
/dev/vda1 46G 44G 0 100% /
tmpfs 7.4G 0 7.4G 0% /dev/shm
tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup
/dev/vda15 99M 3.6M 95M 4% /boot/efi
/dev/mapper/LVMVolGroup-DATA_VOLUME 138G 17G 114G 13% /mnt/data
tmpfs 1.5G 0 1.5G 0% /run/user/0
Even if there are 2GB of free space on / , it shows that the filesystem is at 100% of usage, and I can't install new packages because it tells me there's no space left on device.
Besides, if I type sudo du -sh /* | sort -rh | head -15
the result is:
17G /mnt
1.1G /usr
292M /var
208M /root
139M /run
49M /boot
48M /tmp
32M /etc
28K /home
16K /lost+found
12K /anaconda-post.log
4.0K /srv
4.0K /opt
4.0K /media
0 /sys
So it seems that there are no big files filling up the disk, and the sum of the sizes of the directories is not even equal to 44GB.
Additional info: the only service running on the server is Jenkins, but its home is under /mnt/data/jenkins.
How can I solve the problem?
Found the solution.
The problem was related to some deleted files kept open by Jenkins.
Restarting the service the problem was solved.
The problem was related to the system cache/temp storage. Linux system created the cache files and its archive from time to time, especially when some long option is run like DB import or crone job etc.. or sometimes server up from sines long.
Restarting the service or server
so due to that, the cache/ temp files were deleted and the problem was solved.
even in windows, we faced that kind of performance issue when RAM is low, and restarting the system is the primary solution for that.
I'm having difficulties to understand the disk size of my qcow2 image.
I have a CentOS 6 box running:
# virsh version
Compiled against library: libvirt 0.10.2
Using library: libvirt 0.10.2
Using API: QEMU 0.10.2
Running hypervisor: QEMU 0.12.1
I run couple guests there and without much activity on the guests I noticed the backup ( I do manual complete file copy with cp, no qcow2 based snaps) on one of my guests has grown 4 times. The other guests seem to behave normally and have normal backup size growth.
When I login to that guest I see that
# df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 396M 5.5M 391M 2% /run
/dev/mapper/debian9--vg-root 188G 2.7G 176G 2% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/vda1 236M 62M 162M 28% /boot
tmpfs 89M 0 89M 0% /run/user/0
but the qcow2 file has grown from 5GB to
# du -h /backups/vm01/20180111/vm01.qcow2
19G /backups/vm01/20180111/vm01.qcow2
I found the size of qcow2 disk file grows rapidly and tried to "qemu-img convert" the backup file, but did not solve the problem. When I did dd if=/dev/zero of=vm01.qcow2 it ran until I ran out of space on that volume group ( more than the 19G ). I was expecting the qcow2 file to grow more or less with the size of the internal file system. Any hints what I may be doing wrong?
Regards,
Pavel
Unless you have TRIM/DISCARD enabled for the host filesystem, QEMU and the guest OS, the qcow2 file will never shrink in size. So most likely explanation is that something in the guest OS created a very large file for a short time and then deleted it again. the qcow2 image would have grown to hold this file, but once the file was deleted, the qcow2 image won't shrink again, without TRIM/DISCARD being available.
I used Cassandra to store my data. I use Centos.
The data seems always to be stored in the root partition, which is too small.
My file system partitions like
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 50G 25G 26G 49% /
devtmpfs 7.8G 0 7.8G 0% /dev
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 7.8G 17M 7.8G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/sda2 494M 177M 318M 36% /boot
/dev/sda1 200M 9.8M 191M 5% /boot/efi
/dev/mapper/centos-home 873G 66G 807G 8% /home
tmpfs 1.6G 0 1.6G 0% /run/user/1001
Obviously the root partition (50 GB) is much smaller than one at home (873GB).
Is there a way that I change a setup to enforce data storage using the
partition "/dev/mapper/centos-home" ?
I need to use the command "sudo service cassandra start" to activate Cassandra.
If without sudo, my authority doesn't allow me to activate Cassandra.
Thanks!
Edit the $CASSANDRA_HOME/conf/cassandra.yaml file (sometimes it is
located under /etc/cassandra also, depending on how you install
Cassandra)
Update the following properties
(only available since Cassandra 3.x) hints_directory: /var/lib/cassandra/hints // put your own directory here
data_file_directories: //put a list of directories here
/var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog // put your own directory here
saved_caches_directory: /var/lib/cassandra/saved_caches // put your
own directory here
I am currently using the last version of owncloud. Since the installation, I cannot login anymore. A quick look at /var/log/apache2/error.log explains why :
WARNING: could not create relation-cache initialization file "global/pg_internal.init.7826": No space left on device
DETAIL: Continuing anyway, but there's something wrong.
WARNING: could not create relation-cache initialization file "base/17999/pg_internal.init.7826": No space left on device
DETAIL: Continuing anyway, but there's something wrong.
WARNING: could not create relation-cache initialization file "global/pg_internal.init.7827": No space left on device
DETAIL: Continuing anyway, but there's something wrong.
WARNING: could not create relation-cache initialization file "base/17999/pg_internal.init.7827": No space left on device
DETAIL: Continuing anyway, but there's something wrong.
WARNING: could not create relation-cache initialization file "global/pg_internal.init.7828": No space left on device
But I cannot figure where I do not have enough space. If I try df -h as root, everything seems ok to me :
:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 20G 20G 0 100% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 4.0K 3.9G 1% /dev/shm
tmpfs 3.9G 82M 3.8G 3% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda2 898G 912M 851G 1% /home
tmpfs 788M 0 788M 0% /run/user/0
Excepted the first line which I hardly understand what it represents. I installed owncloud into /home/owncloud so I bet everything should be ok.
Any idea?
Edit :
Results of findmnt :
~# findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda1 ext4 rw,relatime,errors=remount-ro,data=ordered
~# findmnt /dev/sda1
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda1 ext4 rw,relatime,errors=remount-ro,data=ordered
~# findmnt /dev/sda2
TARGET SOURCE FSTYPE OPTIONS
/home /dev/sda2 ext4 rw,relatime,data=ordered
Often, these programs store their data under /var, In your case, you don't have a separate mountpoint for /var so it's a directory on your root file system /. This is full and so the program is not working.
Before you attempt a resize or anything, I think you should find out what is hogging 20GB. du / | sort -n should give you a rough idea of the guilty parties or you can use a graphical tool like xdiskusage. Clean it up and you'll be good to go.
The other alternative is to look through the config files for owncloud and make it use your home directory to store its data. That way, it will work. But you should clean up your /. Various things will misbehave if you don't.
Maybe you are out of inodes: No space left on device – running out of Inodes.
Use df -i to check that. It happened to me as my backup used to have millions of small files. So there was space left but no inodes left.
How to increase disk space of an instance without using EBS ? Root file system size is only showing 10 GB. Is there a way to create a bigger file system without EBS ?
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.9G 3.3G 6.1G 35% /
tmpfs 874M 0 874M 0% /lib/init/rw
udev 874M 84K 874M 1% /dev
tmpfs 874M 0 874M 0% /dev/shm
/dev/sdb 335G 12G 307G 4% /mnt
As you can see in the output, a much bigger partition is mounted at /mnt. You can move some of the things on the root filesystem there by either remounting it at the appropriate location or add symlinks. There is no other way to add more diskspace if you don't want to resort to EBS or a network filesystem.