Log viewer

cmswest wrote on Tuesday, November 11, 2014:

my test on Ubuntu 12.04 works on past activity

fsgl wrote on Tuesday, November 11, 2014:

Thanks, Stephen. Vermonters are the best.

Hopefully now Paul can find the relevant errors. Even with the superfluous stuff, the fatal errors are clearly labelled in the error log.

Past activity also fine on LM17, which is the equivalent of U14.04.

lamspc wrote on Wednesday, November 12, 2014:

Thanks for all the suggestions.

The E-Notice error logging is set as follows:

; E_NOTICE - run-time notices (these are warnings which often result

Could it be the size of the log table - it now has 13 million rows of records when I looked at the table through phpmyadmin. Should I compact these - any suggestions
?

cmswest wrote on Wednesday, November 12, 2014:

error reporting is not set there, that’s just a comment in the file

go down to around line ~520 and find something like this:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

and change it to

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE

interesting point about the size of the table but i don’t think that’s the issue here

it may be worthwhile to archive a table, i’ll look into that some more

fsgl wrote on Thursday, November 13, 2014:

The apache 2 error log will have a time assigned to each message.

To help you wade through the harmless notices; open Log Viewer, take note of the time, immediately proceed to the error log & look for a fatal error at the noted time.

It’s highly unlikely that the log has no fatal error corresponding to the time that you attempted to open it. Patient examination should locate the desired text. It will be clearly labelled as “fatal error” at the beginning of the message.

tmccormi wrote on Thursday, November 13, 2014:

You can also use grep to filter for the word Fatal … assuming a linux
install or on windows install cygwin or similar tool set…

for example

cd /var/log/apache2

grep Fatal [your error log name here]

xxxx_error_log:[Mon Aug 18 17:33:14 2014] [error] [client 72.185.121.166]
PHP Fatal error: Maximum execution time of 60 seconds exceeded in
/mnt/datadrive/opt/www/vhosts/
xxxx.mi-squared.com/emr_xxx_prod/openemr/library/clinical_rules.php on line
575, referer: https://,

Tony


Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.

fsgl wrote on Friday, November 14, 2014:

Great tip.

Will go into my informal “sticky posts”.

lamspc wrote on Monday, November 17, 2014:

I have some good news - but alas, no solutions yet.

sudo cat /var/log/apache2/error.log | grep “Fatal”

shows there are NO fatal errors.

The problem is that it takes about 15 minutes for the log viewer query page to appear after clicking the ‘log’ link on the left panel. And then, executing the simplest query with a short time window takes another 15-20 minutes, during which period openemr is inoperable. I had previously not waited - and simply assumed it had frozen from an error.

The problem it appears lies with my system resources:
when I click ‘log’, the PID mysql suddenly rises to the top resource user - ~14% of CPU and 16% of memory. My openemr server has only 512MB RAM - it is fast enough for everyday use, but this log view issue.

I guess we could rest this issue - will give an update if/when I migrate to a server with bigger memory.

fsgl wrote on Monday, November 17, 2014:

We had long waiting times for MU1 reports to run. Brady was able to cut hours down to minutes.

Have a look at this. Perhaps it contains clues how to speed things up with your present resources.

There is also the option of adding more memory, which is fairly cheap on EBay or Amazon. Not a big engineering project for most devices.

bradymiller wrote on Monday, November 17, 2014:

Hi,

I took a quick look at the log view script and the main query.

1.Possibly is the query collected via “select distinct event from log order by event ASC”. To optimize this try to see if placing an index on the ‘event’ sql column in the ‘log’ sql table speeds this up. Let us know if it works. Note that adding indexes to the log table comes at a cost to overall performance of OpenEMR since they slow down the sql insert (and almost everything that is done in OpenEMR is inserted into the log table). There is a chance though that this may solve your problem.

2.Also possibly the main search query which seems inefficient for it’s purposes in library/log.inc since should not need to use LIKE:

    $sql = "SELECT $cols FROM log WHERE date >= '$date1' AND date <= '$date2'";
    if ($user != "") $sql .= " AND user LIKE '$user'";
    if ($patient != "") $sql .= " AND patient_id LIKE '$patient'";
    if ($levent != "") $sql .= " AND event LIKE '$levent%'";
    if ($tevent != "") $sql .= " AND event LIKE '%$tevent'";
    if ($sortby != "") $sql .= " ORDER BY ".$sortby." DESC "; // descending order
    $sql .= " LIMIT 5000";

You could try the following instead:

    $sql = "SELECT $cols FROM log WHERE date >= '$date1' AND date <= '$date2'";
    if ($user != "") $sql .= " AND user = '$user'";
    if ($patient != "") $sql .= " AND patient_id = '$patient'";
    if ($levent != "") $sql .= " AND event = '$levent'";
    if ($sortby != "") $sql .= " ORDER BY ".$sortby." DESC "; // descending order
    $sql .= " LIMIT 5000";

3.Also possibly html issue when trying to display 5000 records (taken from the LIMIT in above query). To test this could decrease the LIMIT to 20 and see if things improves. There should be pagination on this page, then wouldn’t be limited by how many can see.

Hope this helps get you started. Let us know what helps and doesn’t help, so can think about getting this optimized in the main codebase.

-brady
OpenEMR