openEMR 7.0.2 extremely slow

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.

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.

Sorry, I don’t understand, I’m now on version 7.0.2, how do I do that from 6.0?
In the structure it appears in the first record ID type bigint(20), record 44 pid type bigint(20), record 111 uuid type binary(16) all are indexes

Now it seems that it was not the database, I changed the openemr 7.0.2 folder, and replaced it with the openemr 6.0.0(3) folders and the speed is fantastic, so it must be something in the update files of the soft and not in the base

check the tables I listed in other post. I don’t know what table you are showing here but for example:

I need to work on some other tasks but please address all mine and Stephens questions and tasks.
Something happened in upgrade and you may need to redo maybe with updated version of xampp.

I have pc_pid as the key field and the cardanility values ​​are very different. I don’t know if you were able to see the message where I commented that if I put the site in 6.0.0(3) to work with the 7.0.2 database, the speed is excellent.

unsure why you have an index on pc_pid. I can’t find anywhere in upgrades that builds that index!
I doubt that will hurt but hard to say.

you might want to try to a reinstall 7.0.2 directory.