EPrints Technical Mailing List Archive

Message: #09269

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] {Suspected SPAM} Re: Error calling df: Cannot allocate memory

  • To: "Agung Prasetyo W." <prazetyo@gmail.com>
  • Subject: Re: [EP-tech] {Suspected SPAM} Re: Error calling df: Cannot allocate memory
  • From: David R Newman <drn@ecs.soton.ac.uk>
  • Date: Thu, 6 Apr 2023 10:15:34 +0100
Hi Agung Prasetyo W.,

Running quite a few repository servers with 2GB of RAM, I cannot remember the last time I saw this message, if ever.  However, it is possible that 2GB RAM may still not be enough if you have a large EPrints repository with a lot of visitors.  Also, if you are running multiple repositories and / or websites on the same server or have other applications not required by EPrints running on the server, 2GB or even more RAM may still lead to you getting the same error messages you reported.  Therefore, my advice would be if you see this message:

1. Add extra RAM.
2. Make sure any applications not required by EPrints are not running and will not restart after a reboot.
3. Move any other websites hosted on the same server (e.g. by Apache) onto a different server, so your EPrints server is only hosting EPrints repositories.
4. Limit the number of EPrints repositories you are running on the same server.
5. Setup a cron job to make sure the webserver (i.e. Apache) is restarted every night to clear any memory leaks.

The last of these is not a great option and I would only use as a last resort.  It may be that even restarting once a day still does not ensure there is enough memory to avoid the error message you have been seeing.  I only suggest this as a stopgap solution until you and implement one of the earlier options in the list.

Regards

David Newman

On 05/04/2023 9:19 am, Agung Prasetyo W. wrote:
CAUTION: This e-mail originated outside the University of Southampton.
Hi David,

Thank you for your reply. 

I also thought that the lack of memory was the cause of this error. It seems I have to check how much memory is installed on the server. If the memory is above 1GB and this error still appears, does that mean I have to check via htop whether there are other processes that are reducing memory?

Thank you.

Regards,
Agung Prasetyo W.

On Wed, Apr 5, 2023 at 2:28 PM David R Newman <drn@ecs.soton.ac.uk> wrote:
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://www.eprints.org/eptech/msg08276.html, but still no solution. 

Thank you.
Regards,





*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/