mysql> show indexes from playsms_tblSMSOutgoing;
+------------------------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------------------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| playsms_tblSMSOutgoing | 0 | PRIMARY | 1 | id | A | 108290 | NULL | NULL | | BTREE | | | YES | NULL |
| playsms_tblSMSOutgoing | 0 | smslog_id | 1 | smslog_id | A | 108296 | NULL | NULL | YES | BTREE | | | YES | NULL |
| playsms_tblSMSOutgoing | 1 | uid | 1 | uid | A | 8 | NULL | NULL | | BTREE | | | YES | NULL |
+------------------------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
3 rows in set (0.01 sec)
mysql> show indexes from playsms_tblSMSOutgoing_queue;
+------------------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| playsms_tblSMSOutgoing_queue | 0 | PRIMARY | 1 | id | A | 823 | NULL | NULL | | BTREE | | | YES | NULL |
| playsms_tblSMSOutgoing_queue | 0 | queue_code | 1 | queue_code | A | 823 | NULL | NULL | | BTREE | | | YES | NULL |
+------------------------------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
2 rows in set (0.01 sec)
mysql> show indexes from playsms_tblSMSOutgoing_queue_dst
-> ;
+----------------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+----------------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| playsms_tblSMSOutgoing_queue_dst | 0 | PRIMARY | 1 | id | A | 109820 | NULL | NULL | | BTREE | | | YES | NULL |
+----------------------------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
1 row in set (0.01 sec)
Hi, Man!
This is not the right approach, this is a crutch!
History should always be.
Regards,
Jamshid Tursunov
You must provide another ways to access history⦠But, if you think that there is such approach to optimize read/write access to tables with dozens of millions records, please, tell us when you find it.
Thanks for answering.
I am not a database specialist. but I look at the situation from an objective point of view. I didnāt see that in highly loaded systems, although in less loaded systems, the table was periodically cleared, all because indexing was not turned on (I donāt know the cause of the problem, I just rely on your words that you mentioned earlier in this post) or there are underperformances in the architecture of the database.
Regards,
Jamshid Tursunov
Anton, let me also draw your attention to this behavior of the system.
The database is very busy, even if idle.
Regards,
Jamshid Tursunov
try to kill playsmsd one by one, one at a time, and observe
the kill starts from dlrssmsd, then restart playsmsd then kill recvsmsd manually, restart again and so on
see which service affecting mysql
anton
Ok, thank you, will try it.
Regards,
Jamshid Tursunov
Anton, I tried to collect information on each process and together as a whole, and this is what happened:
Sequential shutdown and inclusion:
Before shutting down the processes, the CPU load varied in the range of 105-140%
Disconnected in the following sequence:
The first to disconnect ratesmsd, the CPU load dropped to around 30-50%, and this range, while watching, kept steady
The second turned off recvsmsd, the CPU load was in the range of 30-43%
The third disabled schedule, the CPU load was in the range of 30-42%
The fourth disconnected sendsmsd, the CPU load was in the range of 30-42%
Fifth disabled dlrssmsd, CPU load dropped to 0.7%, sometimes jumped to 1%
When all 5 services disconnected, the CPU load dropped to 0.7%, sometimes jumped to 1%
When I turned on dlrssmsd, the CPU load jumped right up to 30-42%
Next turned on sendsmsd, the CPU load remained in the range of 30-42%
After turning on schedule, the CPU load was in the range of 30-42%
Then turned on recvsmsd, the CPU load was in the range of 30-42%
When I turned on ratesmsd, the CPU load was kept in the range of 40-45%, but very often there are skips and the load reaches as much as 145%
Individual enable and disable: (I will enable and disable the service to calculate how much load a single process gives)
When I turned on dlrssmsd, the CPU load jumped right up to 42%
Next turned on sendsmsd, CPU load kept in the range 1.3-1.7%
After I enabled schedule, the CPU load was in the range 1.3-1.7%
Then I turned on recvsmsd, the CPU load kept in the range 1.3-1.7%
When I turned on ratesmsd, the CPU load started to jump right up to the mark above 100%
ā¦
I want to emphasize that even after I turned off all the PlaySMS processes, the memory occupied by MySQL remained at 14%. I want to say that after disabling the PlaySMS process, the memory is not freed.
Respectfully,
Jamshid Tursunov
Anton, if possible, pay attention to the above MySQL behavior. Is it possible to optimize MySQL in order to reduce the load on the processor. Such bumps occur only with a simple system.
Respectfully,
Jamshid Tursunov
Anton, good day!
Did you have time to look at the unstable behavior of PlaySMS when stacking with a database?
Respectfully,
Jamshid Tursunov
Hi, sorry no, and I think its better to ask MySQL professionals/communities for that.
Looks to me its all on how to correctly index and/or optimize MySQL configs. Of course there are parts where changes can be done in playSMS to help it, but I havenāt got time to focus on that.
anton
Hello dear Anton!
I have to bother you again, your help is needed in solving this issue
If you pay attention, I tried to describe the problem in detail within each service separately.
I really need your help in solving this issue, apparently, except for you, no one will figure this out
Respectfully,
Jamshid Tursunov
whats your serverās specification (cpu, ram, is disk ssd or not) ?
have you try to tweak MySQL config ?
have you try to make index, test it, perhaps ask MySQL pro to help you how to fix it (or follow some index pointed by @Edilson_Spessoto on previous posts
how big your data ? how many estimated rows on your tables ? (just estimation, no need exact number, like above a million, above 1 hundred thousand rows⦠something like this)
anton
Try to shutdown your playSMS then try to observe your MySQL if it behaving the same. Is this a physical machine? or virtual? what is the storage config and physical specs⦠Is there any application uses share same volume with your MYSQL. Would be great if you provide you partition tables, directory where your components directory installed. And you migth check if someone mocking your Mysql server try netstat.
Anton got you there, but need to understand how his hardware specs. Indexing is good but I have Helpdesk system for almost 10 years of data with a 1K users havenāt performed indexing but still donāt have an issues with this databases server.
Just helping here.
From you post, memory physical uses 60% of it, your swap does not even used. meaning you have a pretty good memory utilizations.
But were are not aware on how your storage specs, how you manage the partitions, where/what volumes your application working directory been stored.
You might also check you physical storage performance.
your hardware specs.
@anton , if you have the opportunity and resources, please fix this problem as well.
You can preview a similar situation on the working playSMS
Note:
I tried to collect information on each process and together as a whole, and this is what happened:
Sequential shutdown and inclusion:
Before shutting down the processes, the CPU load varied in the range of 105-140%
Disconnected in the following sequence:
The first to disconnect ratesmsd, the CPU load dropped to around 30-50%, and this range, while watching, kept steady
The second turned off recvsmsd, the CPU load was in the range of 30-43%
The third disabled schedule, the CPU load was in the range of 30-42%
The fourth disconnected sendsmsd, the CPU load was in the range of 30-42%
Fifth disabled dlrssmsd, CPU load dropped to 0.7%, sometimes jumped to 1%
When all 5 services disconnected, the CPU load dropped to 0.7%, sometimes jumped to 1%
When I turned on dlrssmsd, the CPU load jumped right up to 30-42%
Next turned on sendsmsd, the CPU load remained in the range of 30-42%
After turning on schedule, the CPU load was in the range of 30-42%
Then turned on recvsmsd, the CPU load was in the range of 30-42%
When I turned on ratesmsd, the CPU load was kept in the range of 40-45%, but very often there are skips and the load reaches as much as 145%
Individual enable and disable: (I will enable and disable the service to calculate how much load a single process gives)
When I turned on dlrssmsd, the CPU load jumped right up to 42%
Next turned on sendsmsd, CPU load kept in the range 1.3-1.7%
After I enabled schedule, the CPU load was in the range 1.3-1.7%
Then I turned on recvsmsd, the CPU load kept in the range 1.3-1.7%
When I turned on ratesmsd, the CPU load started to jump right up to the mark above 100%
ā¦
I want to emphasize that even after I turned off all the PlaySMS processes, the memory occupied by MySQL remained at 14%. I want to say that after disabling the PlaySMS process, the memory is not freed.
Regards,
Jamshid Tursunov
Most likely, indexing is not enabled for some tables.
Iām certainly not a deep DB specialist, but all sources on the Internet point to this.
Regards,
Jamshid Tursunov
This may paritially be fixed here:
That changes, especially on credit/fn.php
, removed INNER JOIN SQL to tblSMSOutgoing
, when querying balance.
parent_uid
and uid
information also saved in tblBilling now so no need to JOIN 2 tables when querying balance.
For new installation it wont be a problem, but for an upgrade, you need alter tblBilling
by adding parent_uid
and uid
column, and then copy all parent_uid
and uid
info from each row in tblSMSOutgoing
to tblBilling
.
anton
Check soon
Yours faithfully,
Jamshid Tursnuov