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

[EP-tech] Manage deposits page loads very slow

Thanks for the recommendations. I'll try them tomorrow morning.

As for your questions Yuri: the disk speed should be the same as the old
VM. I migrated the whole DB and repository as described on the eprints
wiki, so I guess that should also contain the indexer info, but even if the
indexer started from 0 it should have finished over the weekend (the
repository has 24GB). Stopping the indexer does not change anything, might
this mean that it is not running correctly? No errors shown in the indexer
logs to give me an idea.

On Mon, May 21, 2018 at 12:03 PM David R Newman <drn at ecs.soton.ac.uk> wrote:

> Hi Emilian,
> I have a repository that has over 1000 deposits under my user's Manage
> Deposits and it only takes a few seconds to load.  First, can I check
> which MySQL table engine are you using, is it MyISAM or InnoDB?  I know
> that both can have problems dealing with complex queries but sometimes
> for different reasons. I am not aware of any particularly complex
> queries having been introduced to Manage Deposits between the versions
> of EPrints you describe.  However, something I have done to mitigate
> complex queries with a number of repositories I manage, is add the
> following line to perl_lib/EPrints/Database/mysql.pm:
> $self->do('SET @@session.optimizer_search_depth = 3;');
> This should be on roughly line 242 and is in the connect function after
> the line: $self->do("SET NAMES 'utf8'");.  Its purpose is to stop MySQL
> spending too much time working out the optimal way of running the query
> before actually running it.  I have to admit, I am not overly confident
> this will fix your issue but I do not really have enough information to
> suggest anything else and this sort of issue is one that is difficult
> to debug remotely over email.
> Regarding MySQL and Apache using a lot of memory; these, particularly
> the latter, will tend to use as much memory as they can, so if you
> increase the RAM they will try to make use of it.  This is rarely
> memory that cannot be released if needed by another process, so should
> not really cause a problem. However, limiting the amount of
> threads/processes Apache can run may be useful.  Particularly, in the
> event of a DDOS attack, as you are more likely to be able to still SSH
> into the server to investigate what is going on.  I use the following
> (Apache 2.4) configuration in
> /etc/httpd/conf.d/performance_tuning.conf:
> <IfModule mpm_prefork_module>
>   StartServers                    2
>   MinSpareServers                 2
>   MaxSpareServers                 5
>   ServerLimit                     30
>   MaxClients                      30
>   MaxRequestsPerChild             100
> </IfModule>
> RewriteEngine on
> RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
> RewriteRule .* - [F,L]
> If you are running Ubuntu 16.04 or above the I"fModule
> mpm_prefork_module" will need changing and potentially some of the
> parameters inside that block.
> Hope this helps
> David Newman
> On Mon, 2018-05-21 at 11:26 +0300, Emilian Mitocariu wrote:
> > Hi,
> >
> > I migrated an eprints instance from version 3.3.7 running on a VM
> > with ubuntu 10.04, 1GB RAM and 2 virtual CPUs to the latest eprints
> > version 3.3.15 on a VM with ubuntu 16.04, 2.5GB RAM and 2 virtual
> > CPUs. I followed the page documented on the eprints wiki for the
> > migration.
> >
> > There were no problems with loading pages on the old version, but on
> > the new server when a user visits the "Manage Deposits" page and has
> > a lot of deposits, it takes a while to load the page. For a user with
> > 885 deposits, it takes at least 30 seconds.
> >
> > I compared the mysql configuration on both VMs and it is similar.
> > Also, the eprints indexer is running. During the day, apache and
> > mysql seems to use more RAM than it did on the old VM.
> >
> > Does anyone know what could cause the slow page load or at least give
> > me some pointers where to look?
> > *** 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/
> > *** EPrints developers Forum: http://forum.eprints.org/
> *** 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/
> *** EPrints developers Forum: http://forum.eprints.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20180521/c296be3a/attachment-0001.html