The post has been translated automatically. Original language: Russian
One of the most common questions after starting a new project sounds very simple.:
"How much memory should I allocate to the VM?"
There is no universal answer. The same volume may be excessive for a corporate website and insufficient for a database.
Therefore, after some time after launch, it is better not to guess, but to see how the system uses the allocated resources.
There are several signs that are really worth paying attention to.
The first sign is that the memory is almost always fully occupied.
If there is very little free memory left, and the system regularly starts using the swap partition, this is already a reason to figure out the reasons. It is not always necessary to immediately increase the amount of RAM, but you should not ignore this situation.
The second sign is that the response time has increased significantly after the load has increased.
For example, a website runs fast in the morning, but starts to slow down in the afternoon when more visitors arrive. Sometimes the reason turns out to be in the application or database, but lack of memory is also quite common.
The third sign is that the system itself has changed in recent months.
New services have been added.
The database has increased.
Additional modules have been added.
If the VM has started to perform more tasks, its initial configuration may no longer match the actual load.
There is also a reverse situation.
Sometimes the memory is increased immediately after the first signs of slowing down, without checking the rest of the indicators.
In practice, this does not always help.
If the problem is related to a slow disk, an unsuccessful database query, or an error in the application, the extra gigabytes won't change anything.
That is why it is better to make any changes after analyzing the monitoring, rather than feeling it.
Modern cloud platforms allow you to increase the amount of memory quickly enough.
It is much more difficult to determine the moment when it is really necessary.
If you focus not on assumptions, but on the actual performance of the system, the solution usually turns out to be much more accurate.
Перенос сайта на VPS обычно воспринимают как техническую задачу. На практике большая часть проблем возникает не из-за самой виртуальной машины, а из-за мелочей, которые легко упустить.
Вот несколько проверок, которые действительно помогают избежать неприятных сюрпризов.
1. Убедитесь, что резервная копия действительно восстанавливается
Наличие архива еще не означает, что им можно воспользоваться.
Перед переносом стоит проверить хотя бы одно тестовое восстановление. Это занимает немного времени, зато сразу показывает, что архив не поврежден и содержит все необходимые данные.
2. Заранее уменьшите TTL для DNS-записей
Если изменить TTL за сутки до переноса, обновление DNS пройдет значительно быстрее. В противном случае часть пользователей еще долго будет попадать на старый сервер.
Это особенно заметно у проектов с постоянной посещаемостью.
3. Проверьте отправку почты после смены сервера
После переноса сайт может открываться без проблем, но письма перестают доходить.
Причины бывают разными: настройки SMTP, ограничения провайдера, неверная конфигурация DNS или файрвола.
Лучше проверить отправку тестового письма сразу после запуска сайта, а не ждать обращений пользователей.
4. Не переносите лишнее
На старом сервере часто остаются временные файлы, устаревшие резервные копии, старые версии сайта или каталоги, которые уже не используются.
Перед миграцией полезно провести небольшую ревизию. Это уменьшит объем данных и ускорит сам перенос.
5. Несколько часов наблюдайте за сайтом после запуска
Если главная страница открылась, это еще не означает, что все работает.
Стоит проверить:
- авторизацию пользователей;
- формы обратной связи;
- загрузку файлов;
- оформление заказа;
- журналы ошибок веб-сервера и приложения.
Такие проверки позволяют обнаружить проблемы, которые не видны при обычном открытии сайта.
Вместо вывода
Сам перенос сайта на VPS сегодня редко вызывает сложности. Гораздо чаще проблемы появляются после него, когда оказывается, что забыли проверить какую-то мелочь.
Небольшой чек-лист перед началом работ обычно экономит значительно больше времени, чем последующее устранение последствий.