[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Error calling df: Cannot allocate memory



Hi,

df if in the Unix disk free command.? Normally, if you ran it from the 
command line you would get an output like:

Filesystem???? 1K-blocks???? Used Available Use% Mounted on
devtmpfs???????? 1010704??????? 0?? 1010704?? 0% /dev
tmpfs??????????? 1021040??????? 4?? 1021036?? 1% /dev/shm
tmpfs??????????? 1021040??? 98984??? 922056? 10% /run
tmpfs??????????? 1021040??????? 0?? 1021040?? 0% /sys/fs/cgroup
/dev/vda1?????? 51474044 20500988? 28335284? 42% /
tmpfs???????????? 204208??????? 0??? 204208?? 0% /run/user/1000

For EPrints this is run with certain extra options by EPrints::System's 
free_space function.? Ultimately, in your case I think this is likely 
called by the function that is trying to work out which diskN directory 
to use under your archive's document directory (i.e. 
EPRINTS_PATH/archives/ARCHIVE_ID/documents/diskN/.).

However, here the error message refers to memory not disk space 
suggesting there is not enough memory on your server to run this 
command.? df requires very little memory to run as far as I am aware.? I 
would try running command "top" from your server's command and look for 
two lines like this:

KiB Mem :? 2042080 total,?? 237740 free,?? 469956 used,? 1334384 buff/cache
KiB Swap:? 4194300 total,? 3987964 free,?? 206336 used.? 1291216 avail Mem

If on the top line the free number is very small and the ratio of used 
to buff/cache is very heavily waited towards used, then you may not have 
enough RAM to run your EPrints repository reliably.? (Also, if on the 
second line the used Swap is very high, this is also a sign of a lack of 
usable memory)? So if possible, it is worth adding some more RAM.? Often 
a temporary fix for this is to restart your webserver (Apache). As it 
can sit on a lot of memory making it unusable.

Looking at the previous thread that refers to this they were only using 
1GB of RAM.? I would say that for all but the smallest EPrints 
repositories with very low visitor traffic, 1GB is not going to be 
enough RAM.? I always use at least 2GB RAM, which is a big difference, 
as quite a bit of that first 1GB of RAM will be used just to run the 
Linux system.? How much RAM are you using?? How large is your archive 
(i.e. number of eprints according to /cgi/counter)? How much traffic do 
you get (e.g. how big (in megabytes) / many lines are in your last 
complete Apache access log)?

My best guess at why df is likely to show up in error messages like that 
shown below is that it is one of the most common commands called by 
EPrints, as it is important it knows how much space you have left in 
your documents directory.? Also, it if probably one of the few commands 
that regularly calls out to a system command directly as result of a web 
browser request.? Therefore, it is the error message you are likely to 
see but there will likely be other error messages suggesting a lack of 
memory issue but unless you look at the log files on the server or run 
various command from the command line you will not notice this lack of 
memory issue. However, another side effect I would expect is for your 
repository to be very slow to respond to requests.

If you can answer the questions I have and maybe provide the same two 
lines from the "top" command, like what I included above, this may help 
me determine whether this is just a lack of memory issue or whether 
there is some other underlying problem.

Regards

David Newman

On 05/04/2023 5:13 am, Agung Prasetyo W. via Eprints-tech wrote:
> *CAUTION:* This e-mail originated outside the University of Southampton.
> Hi,
>
> Is there any solution for this?
>
>
>   EPrints System Error
>
> |Error calling df: Cannot allocate memory|
>
> I also found this thread at 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eprints.org%2Feptech%2Fmsg08276.html&data=05%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7Ceba753c45252439c534d08db35a7547e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638162765007688700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8rZ6wuRKHdXSdMYdrjfDnZ8g3dMa8jhdIbtWIAVqEps%3D&reserved=0 
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eprints.org%2Feptech%2Fmsg08276.html&data=05%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7Ceba753c45252439c534d08db35a7547e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638162765007688700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8rZ6wuRKHdXSdMYdrjfDnZ8g3dMa8jhdIbtWIAVqEps%3D&reserved=0>, 
> but still no solution.
>
> Thank you.
> Regards,
>
>
>
>
>
> *** Options:http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive:https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=05%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7Ceba753c45252439c534d08db35a7547e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638162765007688700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kwI91GJFHx3D5vqunBov4hkC3nQyEslMUGBjl3mXIMc%3D&reserved=0
> *** EPrints community wiki:https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&data=05%7C01%7Ceprints-tech%40ecs.soton.ac.uk%7Ceba753c45252439c534d08db35a7547e%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C638162765007688700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q496CU3cwYDq%2FcQNABV%2BCYQO90uoP7kMrdBJ0BYr8DE%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20230405/392cb36f/attachment-0001.html