VPS on OpenVZ slows down, the site is unavailable. Ubuntu + LAMP. (many screenshots)?

Question

linux

There is a VPS on OpenVZ with hardware:
VPS in Germany.

This is my second experience with VPS, I have practically no knowledge in setting up a server. The first experience ended with setting up the VPS according to the manuals. The server currently has Ubuntu 11 x86 with Apache and muscle, the system was configured by a familiar system administrator. ISPConfig is used as a panel.

Problem:
Yandex Metrica and Google Analytics write twice a day about the unavailability of a site that hangs on the VPS. The site itself periodically freezes for 30 seconds, sometimes up to a minute. The site runs on a fairly resource-intensive Oplayer audio player engine , modified to work with the LastFM api. When working via SSH from Putty or WinSCP, “freezes” occur, the server seems to stop and does not respond to requests for 5-10 seconds.

Apache log for today:
pastebin.com/6LFM06f6

Screen of the top


command Screen of the htop command Screen of the OpenVZ panel Screen of the OpenVZ panel - Details (limits) I wrote to the support about the inaccessibility of the site, they answered that everything was fine on their part: “i have check it, but cant find any mistake." My thoughts: - Non-optimized server setup. - You need to switch to Nginx to reduce the load on the server. - Another client overloads the physical server, as a result of which, due to the shortcomings of OpenVZ, my VPS slows down. Dear habralyudi, what could be the reasons for such brakes and hanging of the UPU?

Answer 1

Switch to Linode or DigitalOcean (or other xen/kvm hosting) so you don't have to depend on your neighbors. Otherwise, the thought “these are neighbors” will haunt you constantly.
Since your MySQL eats 45% of the CPU, buy it a separate VPS. It is better to have two smaller VPS, but one separately for the database, than a larger VPS for everything at once. In the same DC, so that local traffic is free and almost without latency. And it will be easier to scale.

Answer 2

tcp send buffers also ended many times - wa can be from here. Although it would not give 84%.
And you also don’t have caches in memory - most likely due to the hoster’s clumsy openvz settings (old version / wrong limits / etc). If everything is bad there, then your vps may well not put anything into memory personally at all (and all caches in the common system belong to a fat neighbor).
Memory limits are configured through the ass, vswap is not used.
In general, the simplest advice is to move away from this hoster with such a config. Either on ovz with correct memory limits, or on KVM/Xen.

Answer 3

ask technical support how often and at what time a VM backup is done.

Answer 4

In the output of the top command, pay attention to 84.8% wa - you need to figure it out from here (the hard drive is eating something, either it is bad in itself, or there may be other options).

Answer 5

on a VPS with OpenVZ, I/O problems may not depend on you, but on your server neighbors

Answer 6

An evil pinocchio with php-cgi... well-known picture facepalm.jpg

Answer 7

Only I was surprised by the picture with the htop screen, where one core is 100% loaded, and the rest are not?

Answer 8

Munin put and look at the statistics. And check /proc/user_beancounters

Answer 9

A fairly easy problem met a couple of times.
1. iotop -oka at the moment of sagging.
2. munin to help put watch monitor.
3. If it is 30 seconds that confuses you, then I solved this problem for half a year.
Then you are not digging there !!
Everything is stupid enough to increase the timeout time to 600 in Apache, there were no other solutions.
This problem is common to all hosters. Associated with file system IO and how Apache works. Further if it is required lower a timeout.
In my case, switching to ssd solved the problem at the root.