It is necessary to find the cause of periodic freezes of the Linux/PHP server of the online store.

Good evening.

The task is understood at a technical level; it is necessary not to just "patch" the symptom but to gather correlation between load peaks, the web server, PHP processes, MySQL, and the resource limits of the hosting to identify the root cause of the hangs. In such cases, the bottleneck is often not found in a single PHP log but at the intersection of worker limits, entry processes, slow SQL queries, cron/backup tasks, or I/O constraints.

From our architectural perspective, it is advisable to build the diagnosis in several layers, first capturing the timestamps of incidents and cross-referencing them with access/error logs, MySQL slow log, system metrics CPU/RAM/swap/disk I/O, then checking whether the site is hitting process, memory, or concurrent connection limits, and separately looking at long PHP/SQL queries and background tasks. For the old stack on PHP 5.6, this is especially important, as critical delays are often not recorded as "errors" but manifest as process queues and 503/508 under load.

There are two practical risks that we would consider immediately. First, in a shared/VPS environment, the problem may not only lie in the code but also in hidden resource limitations of the hosting. Second, if the database or web component is unstable due to old architecture, temporary acceleration without addressing the bottleneck will only shift the moment of re-failure.

For initial diagnostics, we use SSH-level analysis, web server logs, MySQL slow log, top/htop, ps, vmstat, iostat, sar, free, ss/netstat, checking cron tasks, worker limits, and configurations of Apache/Nginx/OpenLiteSpeed/PHP-FPM depending on the actual scheme. After this, we can specifically state what exactly is causing the peak load and which option for resolution will be optimal.
…
Regarding your questions. We regularly work with Linux servers on tasks of diagnostics, optimization, and stabilization of legacy infrastructure; we have also dealt with similar periodic hangs in the context of finding bottlenecks at the web server, PHP, and MySQL levels; for diagnostics, we plan to use log correlation, system metrics, process profiling, and server configuration analysis; we work with old PHP projects on 5.x in terms of support, diagnostics, and stabilization; initial diagnostics cost 25,000-45,000 UAH depending on the depth of access and the volume of historical data; further work is 1,200–2,000 UAH/hour; we can start after receiving access and a window for data collection, usually in the nearest working slot.

For an accurate start, we just need to clarify what type of hosting is being used, VPS, dedicated, or shared with limits, whether there is access to the MySQL slow log and historical metrics on incidents, and whether the scope includes only diagnostics or also corrections after confirming the cause.

Show original

Translate

Hello. I am ready to discuss the details of your task and take on its execution. I have experience working with Linux servers. As you described in the addition, part of the server issues is due to the increase in the product catalog. For further diagnosis, I need to see the server logs. Write to me, and we will discuss it. Thank you.

Show original

Translate

Hello, I can do it, write to me for help.

Show original

Translate

Good day

I can take on the initial diagnostics. I work with Linux servers, VPS/dedicated servers, PHP/MySQL web stack, and server infrastructure in the context of hosting and data centers.

In such cases, it is important not to look only at PHP logs, as 503/508 errors and spikes in Entry Processes are often not the root cause but rather a consequence. The problem can be in the website or MySQL itself, or at the OS level, disk, I/O, swap, virtualization, hosting limits, or the server's own resources.

It is also important to rule out the infrastructure factor: where the server is located, whether it is shared hosting / VPS / dedicated, what limits are in place, and whether there are issues with the disk subsystem, physical node, or the hosting provider. This is especially true if the project has been running on the same server or plan for a long time.

First, I will check what exactly happens during peak moments: access/error logs, PHP workers / LVE / Entry Processes, MySQL slow queries and locks, CPU/RAM/swap/iowait, disk I/O, cron jobs, OPcache, system logs/OOM, and possible bot traffic.
…
I have worked with PHP 5.x. For an old project, it is important not to make drastic changes "blindly," but to first accurately identify the bottleneck and only then propose a solution.

The initial diagnostics with a brief technical conclusion will cost 3000 UAH.
The estimated time is up to 2 days.

If it turns out that the problem lies with the hosting provider or the physical/virtual node, the time may increase, as part of the checks or fixes will depend on the response and actions of the hosting.

Further work, if needed, will be after agreeing on the scope and cost.

Before starting work, we will discuss the current infrastructure, hosting panel, load graphs, and time intervals when freezes most often occur.

Show original

Translate

The server hangs with CPU/RAM spikes and Entry Processes — a classic picture of PHP process pool exhaustion, but the root cause can vary, so we should start with diagnostics rather than just "tweaking the limits."

What I will check first: the MySQL slow query log (queries over 1-2 seconds are often the root of everything), the state of the Apache/LiteSpeed worker pool during peak times via `server-status` or `mod_status`, and `vmstat`/`iotop` to understand whether it is CPU-bound or I/O-bound load. At the same time, I will look at `SHOW PROCESSLIST` and `SHOW ENGINE INNODB STATUS` — PHP 5.6 + old MySQL often lead to deadlocks or table lock storms without any entries in the PHP logs.

The cost of the initial diagnostics with a written report on the root cause and recommendations: 1500 UAH. The hourly rate for further work: 500 UAH/hour.

What CMS or framework is under the store, and is there a possibility to connect at the moment of the next hang (or are there saved metrics from the time of the incident)?

Show original

Translate

Good day! This is our profile — diagnosing Linux server hangs under load. The symptoms already indicate the direction:
— HTTP 508 = resource limit reached (processes/memory), typically during a spike;
— 503 + Client.Timeout = backend (PHP-FPM/Apache + MySQL) is overwhelmed, unable to respond.

How I will search for the ROOT CAUSE, not the symptoms:
1. By logs + load graphs, I catch the moment of hanging → correlate with CPU/RAM/IO/MySQL connections;
2. PHP-FPM/Apache (max_children, slow requests), MySQL slow-log, OPcache;
3. PHP 5.6 + 15-year-old code — a frequent culprit: heavy/unclosed requests, lack of indexes, table locks;
4. Report: root cause + why it is the cause + optimal solution (without crutches).
…
Please clarify: VPS hosting or shared/panel? Is the hanging scheduled or under traffic/cron? Ready to take it on.

Show original

Translate

Hello, Roman!
You have an online store based on a Linux/PHP server that periodically hangs, negatively affecting the store's operation. To find the cause of these hangs, I will start by analyzing the server log files to determine which processes or requests may be causing these issues. I have experience dealing with similar problems, so I can immediately see where the nuances of server-side optimization will be and which parameters need to be checked.
I will provide the final price and timeline as soon as we clarify a couple of details.
Profile: Freelancehunt
Reviews: Freelancehunt

Show original

Translate

Hello! I am ready to help with your project. I have extensive experience in development and can implement all necessary components according to your documentation. I guarantee quality execution within the agreed deadlines.

Show original

Translate

We already have a practically ready approach for diagnosing old PHP/MySQL stores, we can quickly adapt the checks to your server and discuss the initial actions here ))
We have over 10 years of experience with Linux servers, SSH, web servers, and MySQL, including periodic hangs, 503, 508, and old PHP 5.x projects.
Initial diagnosis - 6000 UAH, approximately 1-2 working days.
Further work after agreement - 1200 UAH per hour.
I can start in the nearest working slot after SSH, panels, logs, and graphs.
First, I will check not only PHP logs but also LVE or Entry Processes, Apache or Nginx or OpenLiteSpeed queues, the number of workers, hosting limits, and peak moments.
Next, I will compare access logs, error logs, MySQL slow log, SHOW PROCESSLIST, locks, iowait, swap, OOM, cron, bots, OPcache, and long queries during hang times.
Look, there’s a nuance here - 508 often indicates not a PHP error as such, but a limit on processes or blocked workers, so we need to look at the server at peak moments, not just after.
I will clarify two points.
… Is there CloudLinux or LVE limits on the hosting?
Do the peaks coincide with cron, product imports, parsers, or advertising traffic?
Similar examples in terms of operational logic.
https://business.ingello.com/prime-eva - an online store and retail where stability, accounting, and load are important.
https://business.ingello.com/carveli - an online store with integrations and operational logic.
Our FLH landing for such tasks - https://systems-fl.ingello.com/ua

Show original

Translate

Please advise: at what times do the freezes most often occur, is it VPS/dedicated or shared hosting, and can you provide web server/MySQL errors for those periods? Have there been any recent changes (updates, imports, cache/plugins)?

We have 4+ years with Linux servers, MySQL, and performance; we have often found the root cause of 503/508 (PHP-FPM/OPcache limits, MySQL locks/slow, IO/OOM, bot traffic). Tools: htop/atop, iostat/sar, ss, dmesg/journalctl, web server status, PHP-FPM/OPcache logs, MySQL slow log + pt-query-digest, correlation with graphs. We have worked with PHP 5.x. Initial diagnostics: $100 (up to 5 hours), further rate $20/hour. Start — today. First, we will check CPU/RAM/Entry Processes/IO limits, PHP-handler/OPcache configuration, slow queries/locks, bot traffic, and kernel/OOM.

We are ready to connect via SSH and start. We will send a short list of accesses and agree on an action plan.

Show original

Translate