My oracle application test instance is down, When I browse through the Unix server, I couldn’t find any files in the mount point,U01 U06 or U10, when I put BDF command it shows the following
$ bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 35571 158662 18% /
/dev/vg00/lvol1 299157 38506 230735 14% /stand
/dev/vg00/lvol8 1392640 1261068 123620 91% /var
/dev/vg00/lvol7 1327104 825170 470631 64% /usr
/dev/vg00/lvol4 716800 385891 310746 55% /tmp
/dev/vg00/lvol6 872448 814943 53936 94% /opt
/dev/vg00/lvolssh 32768 13243 18306 42% /opt/openssh
/dev/vg00/lvol5 204800 187397 16334 92% /home
/dev/vg00/lvolback 512000 472879 36704 93% /backup
dg-ora04:/dgora03_u10
204800 167088 35416 83% /u10
dg-ora04:/dgora03_u06
204800 167088 35416 83% /u06
dg-ora04:/dgora03_u01
204800 167088 35416 83% /u01
Please let me Know why I cant see any files inside the mount points.
If you see no files, consider running fsck on the filesystem. The file metadata has a problem. Also, the lost+found directory may have lots of those files listed in it after fsck runs.
Are these file devices presented on a lun? You may have to play with the volume manager to get things back on track.
Plus, the root cause of your problem is probably: The files look like they are NFS mounts - which, BTW, is a colossal non-no as far as oracle is concerned. Even with NFS 4, you can get into a lot of pain using remote mounted filesystems with oracle file I/O drivers.
Related
I am trying to replace my local development machine with Google Cloud Sheel. When running yarn on Cloud Shell, the system says I am out of space. But df tells me there is lots of space remaining (only 68% used on /home)
#cloudshell:~/***$ df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 62742040 43483680 19241976 70% /
tmpfs 65536 0 65536 0% /dev
tmpfs 8200748 0 8200748 0% /sys/fs/cgroup
/dev/disk/by-id/google-home-part1 5028480 3229288 1520716 68% /home
/dev/sda1 62742040 43483680 19241976 70% /root
/dev/root 2006736 1012260 994476 51% /lib/modules
shm 65536 0 65536 0% /dev/shm
tmpfs 8200748 904 8199844 1% /google/host/var/run
user#cloudshell:~/**$ pwd
/home/user/***
user#cloudshell:~/***$ mkdir test
mkdir: cannot create directory ‘test’: No space left on device
Am I missing something? Why does the system say out of space when there is 32% left?
According to the Cloud Shell documentation:
Cloud Shell provisions 5 GB of free persistent disk storage mounted as
your $HOME directory on the virtual machine instance.
...
If you encounter a no space left on device error, you'll need to remove files from your home directory using the Cloud Shell terminal to free up space.
So it is possible that when it reaches a certain threshold of disk usage that message will pop up.
I'm having the strangest problem for days now. I took over a WordPress website of a company that was originally developed by another person – the codebase is a mess but I was able to go over it and make sure it at least is working.
The database is huge (70mb) and there is a lot of plugin dependencies on the site.
However the site works generally without issues now and I'm hosting it on an EC2 with a bitnami stack for WordPress.
The weird thing though is that everyday (for instance today morning) I check the site and it's down …
Service Unavailable The server is temporarily unable to service your
request due to maintenance downtime or capacity problems. Please try
again later.
Additionally, a 503 Service Unavailable error was encountered while
trying to use an ErrorDocument to handle the request.
When logging into the server with ssh and trying to restart apache I get this:
Failed to unmonitor apache: write /var/lib/gonit/state: no space left
on device Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : apache not
running Syntax OK (98)Address already in use: AH00072: make_sock:
could not bind to address [::]:80 (98)Address already in use: AH00072:
make_sock: could not bind to address 0.0.0.0:80 no listening sockets
available, shutting down AH00015: Unable to open logs
/opt/bitnami/apache2/scripts/ctl.sh : httpd could not be started
Failed to monitor apache: write /var/lib/gonit/state: no space left on
device
I had this the 3rd time in 3 days now even though I restored the server from a snapshot with a volume of 200gb (for testing purposes) and all site files including uploads only have 5gb.
The site is running on an EC2 (t2.medium) with 200gb volume now and today morning I can't restart apache. Yesterday evening when restoring from a snapshot the site works well and normal - it's actually even fast.
I don't know where to start investigating here. What could cause the server to run out of disc space in one night?
Thanks,
Matt
Also one of the weirdest things it seems. I reset everything yesterday eventing from an EC2 snapshot to a 200gb volume and attached it to the instance. Everything was working fine. I made some changes on the files, deleted some plugins, updated some settings.
And it seems this is all gone now. And I'm using an elastic IP, so I couldn't connect to a wrong device or something.
Bitnami Engineer here, you will probably need to resize the disk of your instance. But you can investigate those issues later, these commands will show the directories with large number of files
cd /opt/bitnami
sudo find . -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
du -h -d 1
If MySQL is the service that is taking more space, you can try adding this line under the [mysqld] block of the /opt/bitnami/mysql/my.cnf configuration file
expire_logs_days = 7
That will force MySQL to purge the old logs of the server after 7 days. You will need to restart MySQL after that:
sudo /opt/bitnami/ctlscript.sh restart mysql
More information here:
https://community.bitnami.com/t/something-taking-up-space-and-growing/64532/7
What you need to do is increase the size of partition on the disk and the size of file system on that partition. Even you increased the volume size, these figure kept unchanged. Create another from snapshot would not help too.
Check how to do it here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
Your df result shows
Filesystem 1K—blocks Used Available Use% Mounted on
udev 2014560 0 2014560 0% /dev
tmpfs 404496 5872 398624 2% /run
/dev/xvdal 20263528 20119048 128096 100%
tmpfs 2022464 0 2022464 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 2022464 0 2022464 0% /sys/fs/cgroup
/dev/loop0 18432 18432 0 100% /snap/amazon—ssm—agent/1480
/dev/loopl 91264 91264 0 100% /snap/core/7713
/dev/loop2 12928 12928 0 100% /snap/amazon—ssm—agent/295
/dev/loop3 91264 91264 0 100% /snap/core/7917
tmpfs 404496 0 404496 0% /run/user/1000
where the root volume /deb/xvda1 has only 20GB and that is marked as 100% of the volume, not 200GB as you mentioned.
When you increase the volume size during the instance running, it is not automatically applied. In your EC2, you have to apply the change of volume as follows:
sudo resize2fs /dev/xvda1
and check the size of the volume by doing df -h then you will see the size is now 200GB.
I'm running a docker container that seems to have insufficient memory and I'm not sure how to solve this problem.
I'm essentially running a program on this docker container that downloads an image into tmpfs, performs some operations, deletes the the image and returns a result. However, it seems like I'm running into images that are too large to store in my current docker tmpfs. Below is the output of the linux df command while inside the container:
Filesystem Size Used Avail Use% Mounted on
overlay 63G 11G 50G 18% /
tmpfs 64M 0 64M 0% /dev
tmpfs 6.9G 0 6.9G 0% /sys/fs/cgroup
/dev/sda1 63G 11G 50G 18% /etc/hosts
shm 64M 4.0K 64M 1% /dev/shm
tmpfs 6.9G 0 6.9G 0% /sys/firmware
I've tried expanding docker's memory (hence the huge values on two of the tmpfs's) but I'm still running into this problem.
I guess I have a couple of questions:
1) what is the difference between the 3 separate tmpfs filesystems? Why do they exist?
2) Presumably I need to expand the first tmpfs size (the small one) -- how would I go about doing that?
Finally, some relevant system information:
OS -- OSX
Docker version -- Docker version 17.09.0-ce, build afdb6d4
Let me know if there's other stuff you need to know!
Thanks everyone.
Okay, ultimately figured out the answer. My original two questions were kind of off base.
Essentially, my docker instance didn't have enough memory -- the tmpfs files were red herrings. I ended up needing to pass in a --shm-size="4096m" argument to my docker start command (increased memory to 4096 megabytes) in order to allow my function to properly execute. Hope this helps someone down the road!
Also, for google purpose, the exact error I was getting was There is not enough space available on the shmfs/tmpfs file system. relating to Abbyy FineReader
If you are using Kubernetes, then you need sufficient space in /dev/shm.
In my case, there wasnt enough space in /dev/shm hence Abbyy would bail out before extracting Meta-images. After giving /dev/shm a volume mount, it worked fine. Hope this helps!
I changed size of my persistent disk from 10GB to 20GB.
Screenshot
Now when I run df command in my server, I can still see only 10GB space.
user#edudrona-prod-vm:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10186040 6755924 2889652 71% /
udev 10240 0 10240 0% /dev
tmpfs 1535964 8528 1527436 1% /run
tmpfs 3839908 0 3839908 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 3839908 0 3839908 0% /sys/fs/cgroup
tmpfs 767984 0 767984 0% /run/user/1003
I am just running simple Wordpress site using Bitnami. Except from changing 10GB to 20GB, I did not make any change to increase disk space. Do I have to play around with settings anywhere else as well?
Update:
I got following output from resize2fs command:
user#edudrona-prod-vm:~$ sudo resize2fs /dev/sda1
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 2620416 (4k) blocks long. Nothing to do!
Take a look at the documentation here.
resize2fs alone is not sufficient because what it does is resizing to fill the extents of the carrier partition, but your /dev/sda1 is still the old size. You need to resize that first. On some operating systems the whole root partition upsizing is done automatically on boot, so try rebooting to see if just that does the trick. Otherwise, you'll need to follow the manual steps. Be careful and make sure to back things up first.
I created new vm instance using "Ubuntu Server 10.04 LTS (Lucid Lynx) - 32 bits" image and m1.small falvour which has 20 GB Disk (OpenStack Icehouse). When i logging to the vm and run df -h , I found that the VM does not use the entire assigned HD. The command results are shown as the following:
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 1.4G 595M 721M 46% /
none 1005M 144K 1005M 1% /dev
none 1007M 0 1007M 0% /dev/shm
none 1007M 36K 1007M 1% /var/run
none 1007M 0 1007M 0% /var/lock
none 1007M 0 1007M 0% /lib/init/rw
The "fdisk -l" shows the DH size is 20 GB:
Disk /dev/vda: 21.5 GB, 21474836480 bytes
4 heads, 32 sectors/track, 327680 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cb9da
Device Boot Start End Blocks Id System
/dev/vda1 * 17 32768 2096128 83 Linux
I need the vm to take the full space assigned to it. Any idea how could I fix it? I want the solution to be applied on each vm I create, so I do not want to manually update the VM after instantiation. I also must use 10.04 image ( can not upgrdate to 14.04)
The problem here is the image. I grabbed that one and ran it up, it's pretty simple to run a
sudo resize2fs /dev/vda1
which will resize the filesystem to the size of the partition, which seems to be 2GB. Beyond that, you have to increase the partition size. For that I think you're probably best off using virt-resize, there are some good howto's out there e.g. askubuntu, in essence:
SSH into your openstack controller node
source keystonerc_admin (or whatever yours may be called)
nova list --all-tenants | grep <instance_name> or just grab the server guid from horizon
nova show <server_guid> and note which nova host your machine is running on. Also note the instance name (e.g. instance-00000adb)
SSH into that nova node
virsh dumpxml instance-00000adb and look for the image file. On mine, this is /var/lib/nova/instances/<server_guid>/disk but that may not always be the case?
yum install libguestfs-tools
truncate -r /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
truncate -s +2G /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
virt-resize --expand /dev/sda1 /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
mv disk disk.old ; mv disk.new disk
NB - mine didn't quite work when I booted that up again, not got time to investigate yet but it can't be far off that, and hopefully this helps.
Once you've managed to boot that up again, then you can shut it down and create a snapshot from horizon. You can then use that snapshot just like any other image, and launch all subsequent VMs directly from there.
HTH.