Search results

Following on from this the PID number does appear to be cycling. So the queries are completing sensibly. Looking at the physical and virtual memory use - There is quite high memory use per PHPFPM activity so if we can bring this down then it would improve the situation.

I can see a few processes with the same PID hanging around but I have no idea how to identify what is actually continuing to run. The number of users is changing from approx 12 to 21 but has fallen to between 12 and 15 while I have been watching approx.. And threads reasonably stable from 2-10...

Ok Any ideas how I can investigate further? Am I looking for a bad PHP process on the website or am I looking for a PHP setting to change the behaviour?

It doesnt occupy the phyiscal memory which you can see in the figures in the monitoring panel - Which we discussed But it does then occupy 90% of the available memory as cache value and refuses to release it. This can be seen in h top and plesk > process list. From the two threads I can see...

Ultimately we may end up doing that. Its very frustrating because the real problem is not to do with hitting a hard limit - The memory just isnt being used efficiently enough by the system Thank you for your input. I'll see about reducing the max_heap_table_size as that would make a lot of...

We did increase the sort and join buffers as part of trying to resolve the issue. But Max connections could easily be halved. We've only ever ran out of connections on one server and that was because max connections was 150 and there were over 150 websites on the server with 150 dbs. The...

If you look at the Process list from within plesk or h Top MariaDB eventually occupies the entire 40GB of ram (it stops growing when it consumes about 90%). The process list and h top both show the ram usage including cache values at 100% used. So the actual physical usage at 15-20gb is...

my.cnf [mysqld] max_connections=300 sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION bind-address = 127.0.0.1 local-infile=0 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 10 log_queries_not_using_indexes = 0 Separate included...

Its 100% including cache value. The physical ram use is relatively stable. The mysql memory usage just keeps rising uncontrolably. But this includes both the actual reported values + cached values which are only seen in the process list.

Its not just the backup its everything So over 24-72 hours the ram hits 100% usage with mariadb taking up 90% of that and system the other 10%. If we then get a spike in traffic or an increase in phpfpm requests then the memory still doesnt flush to accomodate those requests. Instead of...

@Bitpalast I've just tagged you in another post I raised about this issue as another user replied. Here is what we have done so far to mitigate the problems: Temp solution - Working very well We have set up a cron job to restart mariaDB at 3am every day. This flushes the db caches so we have...

@WebHostingAce I've been discussing this with @Bitpalast on the post here: https://talk.plesk.com/threads/memory-usage-after-backup.358868/ We have not got a conclusion yet but as @Bitpalast has suggested it appears to be a problem with PHP processes rather than mysql itself. Our Mysql config...

Thanks Bitpalast I appreciate your input on this. I can see you have repeatedly stated you think it is PHP. Im repeatedly saying I dont think it is PHP because if this were the case why would running a backup cause an increase in memory consulption and not release it? Doesnt sound like that...

Unfortunately this leads me nicely back in the same circle again We have not been able to identify anything unusual about the clients website setup that would cause high usage of phpfpm that could be classed as excessive. Mysql continues to clime continually throughout the day. The phpfpm is...

The journal file looks like this: Aug 21 09:44:39 servername.ipaddress.plesk.page systemd[1]: mariadb.service: A process of this unit has been killed by the OOM killer. Aug 21 09:44:41 servername.ipaddress.plesk.page systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL...

This is exactly my point - The memory is getting allocated which can be seen in the graphs and the process list during a spike but its all cache value allocated to mariadb which is getting locked and not cleared. Its the memory not being released that is the issue. Restarting mariadb releases...

We've been through this process. Bad bots have been blocked but this has been going on for an extremely long time. Our old plesk server with 128gb of ram would have the same problem eventually. Its 100% not caused by Bot traffic. On my other post referenced in my reply someone has suggested...

yes indeed. Let me go back to one of the crash situations: Chart showing the 25th-27th August Each purge in data is a mariadb crash caused when the memory hits a critical point vs phpfpm requests OR me clearing the memory as we worked with our hosting provider to adjust the settings The...

@Kaspar jemalloc looks interesting as a solution to the problem - If it can manage the memory pool more efficiently then we may have a winner here. I am going to speak with our managed hosting providers to see if they can impliment on one of our servers as a test.

We've done a lot of work on this - The PHP FPM processes are stable and consistently under 5gb but if we get a spike due to an increase in traffic to lets say 12 gb to a specific page then the memory doesnt flush to accomodate this spike. The problem is the mariadb/mysql memory is not managing...