openEMR 7.0.2 extremely slow

hi @mlobo4370, can you find your innodb settings under the xampp mysql directory?

Sorry for the delay @stephenwaite , I was just attending the office. I tell you that I made the suggested changes before starting work.

My my.ini had this configuration:

Comment the following if you are using InnoDB tables

#skip-innodb
innodb_data_home_dir=“F:/xampp/mysql/data”
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir=“F:/xampp/mysql/data”
#innodb_log_arch_dir = “F:/xampp/mysql/data”

You can set …_buffer_pool_size up to 50 - 80 %

of RAM but beware of setting memory usage too high

innodb_buffer_pool_size=16M

Set …_log_file_size to 25 % of buffer pool size

innodb_log_file_size=5M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50

by changing it to the suggested one:

innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = “/xampp/mysql/data”
innodb_log_arch_dir = “/xampp/mysql/data”

You can set …_buffer_pool_size up to 50 - 80 %

of RAM but beware of setting memory usage too high

innodb_buffer_pool_size=32M
innodb_additional_mem_pool_size=4M

Set …_log_file_size to 25 % of buffer pool size

innodb_log_file_size=8M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout=50

mysql server starts and after a few minutes it turns off, if I comment the line:
innodb_additional_mem_pool_size=4M

It works, but I haven’t noticed any changes in speed.

As I write this I see that there are other options with more buffer, I have tried them with 256 MB, and I still don’t notice any differences.
With innodb_additional_mem_pool_size added the server does not start

estoy esperando la consulta sql de martin para ver si hay algo en la base.
tambien estaba pensando en ver si puedo armar una consulta de actualizacion para modificar todos los datos sensibles de los pacientes y asi ver si le puedo pasar la base a martin para que pueda hacer las pruebas que necesite.
por otro lado, si bien casi no he entrado a las demos, la semana pasada entre para ver de reportar un problema, y tambien la note muy lenta.

I’m waiting for @sjpadgett ‘s sql query to see if there is anything in the database.
I was also thinking about seeing if I can set up an update query to modify all the patients’ sensitive data and see if I can pass the database to @sjpadgett so he can do the tests he needs.
On the other hand, although I have hardly entered the demos, last week I entered to see if I could report a problem, and I also noticed it was very slow.

Thank you all for your support

would increase this to 4G and adjust the log file size accordingly

I make this configuration:

Comment the following if you are using InnoDB tables

#skip-innodb
innodb_data_home_dir=“F:/xampp/mysql/data”
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir=“F:/xampp/mysql/data”
#innodb_log_arch_dir = “F:/xampp/mysql/data”

You can set …_buffer_pool_size up to 50 - 80 %

of RAM but beware of setting memory usage too high

innodb_buffer_pool_size=4096M
##innodb_additional_mem_pool_size=20M

Set …_log_file_size to 25 % of buffer pool size

innodb_log_file_size=1024M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50

I’ll comment in a while.

Are there possibilities to convert the base from 7.0.2 to 6.0 again without losing patient data, to perform the update step by step again to see if there was any problem in the process and the same thing happens?

I just tried with 4g it seems that it even takes longer

OK, try these recommended settings.

Yes! I’d be happy to install your database and track for bugs. Before I did a performance profile and did some fixes back around v6 I saw several sites complain about slow load.
I haven’t yet been able to pinpoint a possible query issue but still looking for a test query to run stand alone.
I don’t have the time to build a test dataset. Wish I did.

About how many appts and patients are current being tracked on flow board load?
Is it loading for just the today date range?
I see even with no appts to track filter is slow.

My dear @stephenwaite and @sjpadgett , as is, for example my flow board today only had 10 appointments, but even with four, it takes between 10 and 15 seconds. I always use it on the current date. On the other hand, although it has nothing to do with speed, since they are looking at the flow board in depth, the statistics it shows are wrong, no matter what doctor or center filter you put, it always shows the total data of all patients who have an appointment that day, in all centers and with all doctors. Finally, not only is the flow board slowed down, to a lesser extent, but the loading of the calendar is slowed down, and other things, including entering the system after logging in.
regards

I have already done it and I have had no changes.
this statement “innodb_additional_mem_pool_size” makes mysql stop

Whenever you want, send me the query and tell me what information I have to tell you to see what’s going on.

You know it sounds like you’ve lost some table keys somewhere. I’ve seen on my database imports sometimes I lost primary key on some tables. I don’t know how and this was when I was doing ONC CCDA testing.

Check some of you main tables like patient_data, openemr_postcalendar_events and others.

My dev system is on xampp 8.2

hi @mlobo4370, pretty sure it’s your innodb settings since you’re having issues in other areas of the emr.

okay to only change innodb_buffer_pool_size to 256M and innodb_log_file_size to 64M and restart the mysql server

I’d be surprised if it was. I’d be more inclined if so to believe it a cache overflow or bad inno thread concurrency setting.
Really need to spot check indexes in tables. I have seen this on database imports on windows/xampp i.e export and import for openemr database.

At the time I didn’t check to see if the indexes didn’t export or if they were lost on import.

My gut is telling me this is going on here.:slight_smile:

Leave these parameters as you suggest. But I never changed anything about innoDB and with PHP 7.4 version 6.0.0(3) worked perfectly

think the db has to do a lot more work in 7.0.2 with the uuids

Could you guide me how I do this so I can verify it? <If so, what would be the solution?

Using your phpMyAdmin search for table to check, open it and click structure.
Look for indexes and primary keys.

I think the problem may be something in mysql, when entering phpmyadmin and selecting the database it took longer than it should, and when you select patients_data, when you set it to show 500 records it took a long time, before it didn’t do it like that

the firts register swowed this:

Nombre Tipo Cotejamiento Atributos Nulo Predeterminado Comentarios Extra Acción

1 id Índice bigint(20) No Ninguna AUTO_INCREMENT Cambiar Cambiar Eliminar Eliminar Más

True and the background service may be bogging system. Good suggestion! They may have been missed being created in upgrade.
@mlobo4370 Try running you sql_upgrade from version v6 and see if your UUIDs are done being created.