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.
Related
I'm using a DS4 Azure VM (Ubuntu 14.04). It comes with a 56GB local SSD.
I need to set up a 25GB swapfile in this local SSD. When I do df -h in the VM, I can see that it seems to be mapped to the /mnt/ folder. Following is the entire output:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 29G 22G 6.4G 77% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 14G 4.0K 14G 1% /dev
tmpfs 2.8G 472K 2.8G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 14G 0 14G 0% /run/shm
none 100M 0 100M 0% /run/user
none 64K 0 64K 0% /etc/network/interfaces.dynamic.d
/dev/sdb1 56G 97M 56G 1% /mnt
However, if I try to initialize a swapfile in /mnt, it still gets added to the available disk space in /dev/sda1.
What do I need to do to set up my swap file? An illustrative example would be great. Thanks in advance.
I normally use the following commands to set up a swapfile:
sudo fallocate -l 25G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Update:
I went into /etc/waagent.conf, and tweaked the followed:
# Format if unformatted. If 'n', resource disk will not be mounted.
ResourceDisk.Format=y
# File system on the resource disk
# Typically ext3 or ext4. FreeBSD images should use 'ufs2' here.
ResourceDisk.Filesystem=ext4
# Mount point for the resource disk
ResourceDisk.MountPoint=/mnt
# Create and use swapfile on resource disk.
ResourceDisk.EnableSwap=y
# Size of the swapfile.
ResourceDisk.SwapSizeMB=26000
After this, I resized (and consequently rebooted) my Azure VM from the portal. Currently I can't tell whether the settings have taken effect. Are my settings correct and what's the best way to ensure they've taken effect?
You are right, we should modify /etc/waagent.conf to add a swap file.
By modifying the /etc/waagent.conf file and setting the following 3 parameters a swap file will be created in the directory defined by ResourceDisk.MountPoint
ResourceDisk.Format=y
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=26000
Then we should restart walinuxagent:
service walinuxagent restart
Commands to show the new swap space in use after agent restart:
dmesg | grep swap
root#ubuntu:~# swapon -s
Filename Type Size Used Priority
/mnt/swapfile file 26623996 0 -1
root#ubuntu:~# df -Th
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 3.4G 12K 3.4G 1% /dev
tmpfs tmpfs 697M 412K 697M 1% /run
/dev/sda1 ext4 29G 869M 27G 4% /
none tmpfs 4.0K 0 4.0K 0% /sys/fs/cgroup
none tmpfs 5.0M 0 5.0M 0% /run/lock
none tmpfs 3.5G 0 3.5G 0% /run/shm
none tmpfs 100M 0 100M 0% /run/user
/dev/sdb1 ext4 99G 26G 68G 28% /mnt
I resized (and consequently rebooted) my Azure VM from the portal
I resized my VM, and the swap file does not lose.
Are my settings correct and what's the best way to ensure they've
taken effect?
After modify the /etc/waagent.conf and restart walinuxagent, we can use swapon -s to check it.
I'm getting following error while doing tab. And unable to change the files, can open the files but not able to save the files. It looks like the server is working fine and long scripts are continuously executing and never ending.
ubuntu#ip-172-31-49-89:~$ cat /etc/issue.net
Ubuntu 14.04.4 LTS
ubuntu#ip-172-31-49-89:~$ uname -a
Linux ip-172-31-49-89 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
ubuntu#ip-172-31-49-89:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 492M 12K 492M 1% /dev
tmpfs 100M 376K 99M 1% /run
/dev/xvda1 50G 47G 0 100% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 497M 0 497M 0% /run/shm
none 100M 0 100M 0% /run/user
ubuntu#ip-172-31-49-89:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 125803 387 125416 1% /dev
tmpfs 127040 315 126725 1% /run
/dev/xvda1 3276800 134435 3142365 5% /
none 127040 2 127038 1% /sys/fs/cgroup
none 127040 1 127039 1% /run/lock
none 127040 1 127039 1% /run/shm
none 127040 2 127038 1% /run/user
ubuntu#ip-172-31-49-89:~$ cd new
-bash: cannot create temp file for here-document: No space left on device
What should I do now? I just deleted my unnecessary founders and files. Still the same error after some time.
I tried solving this issue and my tmp and log files are smaller:
ubuntu#ip-172-31-49-89:~$ du -sh /tmp
1.3M /tmp
ubuntu#ip-172-31-49-89:~$ du -sh /var/log
6.2M /var/log
Well, you said it yourself: you disk is full:
/dev/xvda1 50G 47G 0 100% /
Start investigating where you disk space is gone from the root folder:
du -hs /* | sort -h
That should give a pretty good idea what's occupying most of the disk drive.
I have attached a new volume to an EC2 instance. Volume was attached successfully.Below the output of command.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 32G 8.1G 22G 27% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 2.0G 12K 2.0G 1% /dev
tmpfs 396M 340K 395M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 2.0G 0 2.0G 0% /run/shm
none 100M 0 100M 0% /run/user
overflow 1.0M 1.0M 0 100% /tmp
When i tried to add new cronjob it shows the error that there is no space left.
sudo crontab -e
/tmp/crontab.jVOoWT/crontab: No space left on device
Your /tmp directory is full, first remove the files from your temp directory by issuing the command below
rm -rf /tmp/*
Run your crontab again
sudo crontab -e
Please execute df -i may be inode's 100% full Remove unnecessary file from /var
run your crontab again
crontab -e
I had the same issue on AWS and ultimately the solution was to boost the capacity of the hard drive. Solved the issue.
Hey guys I am new to this Git and Linux..please can you let me know, how to copy data backup (here is backup.tar) to a new disk, as my root directory is showing 100%.
my backup path is : /opt/gitlab-6.5.1-0/apps/gitlab/htdocs/tmp/backups$ls
1419371767_gitlab_backup.tar 1428271073_gitlab_backup.tar
1419458174_gitlab_backup.tar 1428357490_gitlab_backup.tar
1419544598_gitlab_backup.tar 1428443884_gitlab_backup.tar
1419631012_gitlab_backup.tar 1428530316_gitlab_backup.tar
1419717436_gitlab_backup.tar 1428616692_gitlab_backup.tar
1419803830_gitlab_backup.tar 1428703211_gitlab_backup.tar
1419890198_gitlab_backup.tar 1428789555_gitlab_backup.tar
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/server4--vg-root 451G 427G 1.2G 100% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 1.9G 4.0K 1.9G 1% /dev
tmpfs 376M 1016K 375M 1% /run
none 50M 0 50M 0% /run/lock
none 1.9G 4.0K 1.9G 1% /run/shm
none 100M 4.0K 100M 1% /run/user
/dev/sdb1 236M 65M 159M 29% /boot
/dev/sda1 917G 340G 531G 39% /mnt/disk2
/dev/sdc1 917G 75M 871G 1% /mnt/disk3
How do copy to disk3 and remove the backup from the old drive.
Downvoted because it's not a question about git per se, rather a question about Linux...
Anyway, use the mv command to move (or rename) files from one place to another. Or use the cp command to copy them then rm to delete.
Take a look at this tutorial for more help on how to move files around.
Related to: How do I add instance storage to an existing Windows EC2 instance?
My root 60G ebs volume fill up very quickly, and I can't find the culprit in the file system. My actual files only take up about 10G. I've found out that if I "Stop" and then "Start" the instance, it frees up the remaining 50G.
Note: I started the instance as free micro and then later upgraded to m3.medium. Apparantly micro instances don't have ephemeral storage and you can only add "instance store" upon launching an instance. So I'm thinking I don't have access to ephemeral storage and that it is instead eating up my root ebs volume space with temporary files. Is that possible?
#df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 59G 47G 13G 80% /
devtmpfs 1.9G 12K 1.9G 1% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
#du -sh /* | sort -n
0 /proc
0 /sys
4.0K /local
4.0K /media
4.0K /mnt
4.0K /selinux
4.0K /srv
7.3M /etc
8.0K /tmp
8.1M /bin
8.6G /var
9.7M /sbin
12K /dev
16K /lost+found
17M /root
21M /lib64
24K /run
26M /home
49M /boot
59M /opt
122M /lib
858M /usr
The problem had nothing to do with ephemeral storage. It was that httpd wasn't restarting after logrotate.