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.
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 
bigint(20) No Ninguna AUTO_INCREMENT Cambiar 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.