menu download, posted by pudi astuti on Wed Nov 26 09:31:42 2014
|
dear stefan
I have a problem how to bring up the
menu page menu elog download? |
Re: menu download, posted by Stefan Ritt on Wed Nov 26 12:23:01 2014
|
pudi astuti wrote:
dear stefan |
|
menu download, posted by pudi astuti on Fri Nov 28 03:15:17 2014
|
| yes I mean functionally of elog or how to download files at elog? |
|
Elog stability with multiple users, posted by Alan Grant on Wed Feb 18 04:57:32 2015
|
Are there any known or reported daemon stability issues with an increase of concurrent users logged in to view and search entries, while the elog client
is also adding 5 to 10 new entries every minute during a peak 2-hour period each day? |
|
Re: Elog stability with multiple users, posted by Stefan Ritt on Thu Feb 26 10:39:58 2015
|
By desing, there is no collision between different users, since all requests are executed in sequence (single thread). The only problem is that the server
becomes unavailable for others if it executes a long search. This is why most users of large lobooks restrict their search to let's say the last month
or so by default. This speeds up the search and limits the dead time for others. This can be done via the show |
|
Re: Elog stability with multiple users, posted by Alan Grant on Fri Feb 27 23:06:53 2015
|
We have reduced entries for Search reasons by removing older text files and that seems to speed up things.
However, a recurring problem persists during peak period where the service connection is lost (site says "Not
found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010
|
|
Re: Elog stability with multiple users, posted by David Pilgram on Sat Feb 28 14:08:43 2015
|
I grant that this may be a complete red herring, but your description below - not available and having to reboot -
might have another explanation. At least in Linux.
|
|
Re: Elog stability with multiple users, posted by Stefan Ritt on Mon Mar 2 08:06:38 2015
|
Being not able to kill a server running in an endless loop seems strange to me. If you put any program artificially into an endless loop, you can kill it
via "kill -9 <pid>". Have you tried that? The only exception I
can imagine is if there is a problem in the file system, like your elog logbooks are mounted via NFS or some other remote filesystem, and you have a problem |