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.