We are happy to announce that Vesta is back under active development as of 25 February 2024. We are working on v1 candidate and expect to engage more with the community over the coming months. We are committed to open source, and we encourage contributors to help us build the future of Vesta.
RAM после обновления до 17
Re: RAM после обновления до 17
Вопрос к разработчикам!
Как же так, не обкатанную версию кинули в обновление. Это, что шутка такая?
Ну на доже хотя бы какую то ответственность иметь.
Ведь Ваш продукт выбирают за надежность и стабильность работы, а не за то, что он бесплатный.
Лично я не против того если VestaCP станет платная, но только если она будет стабильная и надежная.
Обкатали бы, потом выложили.
Как же так, не обкатанную версию кинули в обновление. Это, что шутка такая?
Ну на доже хотя бы какую то ответственность иметь.
Ведь Ваш продукт выбирают за надежность и стабильность работы, а не за то, что он бесплатный.
Лично я не против того если VestaCP станет платная, но только если она будет стабильная и надежная.
Обкатали бы, потом выложили.
Last edited by Kirill on Sun Nov 27, 2016 6:06 am, edited 2 times in total.
Re: RAM после обновления до 17
Пробежался по паре серверов, топ по памяти
Как бы все адекватно ситуации. У кого проблема - расковыривайте топ, смотрите что жрет память, дальше уже смотрите почему. У меня системные файлы (/etc/my.cnf, /etc/exim/exim.conf и прочее) обновление не тронуло, т.к. как мускул кушал, так он и кушает, как php-fpm кушал - так и осталось. Как бы.
Code: Select all
434MB mysqld
328MB php-fpm
68MB memcached
36MB fail2ban-server
19MB sshd
17MB nginx
13MB named
8MB vesta-php
7MB sftp-server
6MB rsyslogd
Code: Select all
698MB php-fpm
577MB mysqld
273MB systemd
90MB fail2ban-server
69MB nginx
68MB systemd-journal
40MB rsyslogd
31MB sshd
13MB bash
9MB polkitd
Last edited by Stesh on Sat Nov 26, 2016 6:30 pm, edited 1 time in total.
Re: RAM после обновления до 17
На пустом сервере RAM-512 (читая свежая установка) nginx+apache.
Что на CentOS. что на Debian - одинаковая картина.
Code: Select all
MySQL = 2035 мб
Re: RAM после обновления до 17
Покажи stat /etc/my.cnfKirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.Что на CentOS. что на Debian - одинаковая картина.Code: Select all
MySQL = 2035 мб
Re: RAM после обновления до 17
Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?
Не наоборот.. правильно?
Re: RAM после обновления до 17
Кстати, к разработчикам..
Было бы неплохо вывести список изменений. Что бы хоть знать что копать и в какую сторону :((
Было бы неплохо вывести список изменений. Что бы хоть знать что копать и в какую сторону :((
Re: RAM после обновления до 17
Вам, что самому лень.Stesh wrote:Покажи stat /etc/my.cnfKirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.Что на CentOS. что на Debian - одинаковая картина.Code: Select all
MySQL = 2035 мб
Возьмите тестовый сервер, да установите VestaCP nginx+apache. Все увидите сами.
Сколько можно показывать? Не до показов уже (((.
Re: RAM после обновления до 17
Все относительно. Ведь мало кто, у кого проблемы нет, рапортует об этом. Ну ладно, это риторика.korvinod wrote:Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?
Есть проблема? Ок, давайте искать откуда. Речь про обновление на центосе, не чистая установка (при установке панель тянет свои конфиги, которые могут не всем подходить).
Mysql. За его работу отвечает /etc.cnf (и в нем инклуд на /etc/my.cnf.d/, который может использоваться, а может не использоваться). Для того, чтобы изменить работу mysql, нужно а) перезаписать этот файл б) перезапустить mysql.
Т.е. смотрим дату модификации файла + сколько работает mysql, при условии что не перегружалась система (насколько помню, он не перезапускается при обновлении). Если файл модифицировался, смотрим diff с бекапным файлов (ведь все делают бекапы), и бяка может вылезти.
И так далее.
Re: RAM после обновления до 17
1. Мне не лень, но у меня проблемы нет, файл не модифировался (на примере mysql)Kirill wrote:Вам, что самому лень.Stesh wrote:Покажи stat /etc/my.cnfKirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.Что на CentOS. что на Debian - одинаковая картина.Code: Select all
MySQL = 2035 мб
Возьмите тестовый сервер, да установите VestaCP nginx+apache. Все увидите сами.
Сколько можно показывать? Не до показов уже (((.
Code: Select all
# stat /etc/my.cnf
File: `/etc/my.cnf'
Size: 3568 Blocks: 8 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 1307 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-11-26 15:05:02.111951287 +0000
Modify: 2016-06-22 20:28:02.000000000 +0000
Change: 2016-06-22 20:28:06.070779779 +0000
3. Можно не показывать, дело добровольное.
Re: RAM после обновления до 17
результат stat
мускул модифицировался, conf.d пустой, обновлял до php7
Возможно эта инфа поможет
Но как я понимаю проблема у многих, просто не все смотрят графики, сервер доходит до максимума памяти и продолжает работать, сайты не вырубаются, а апдейт только произошел, не все даже поняли что он был, если включен автоапдейт, как назло был включен ) хотя обычно выключаею, просто поставил систему 3 дня назад )))
-/+ buffers/cache used 61 - означает что занято только 61, это изменение поведения кеша в системе возможно?
Почему тогда графики рисуют по-новому, как я понимаю такое поведение в Linux обычно - вся память уходи под кеш?
Code: Select all
File: `/etc/my.cnf'
Size: 717 Blocks: 8 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 134295 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2016-11-26 03:00:02.021543558 +0300
Modify: 2016-11-23 20:15:30.261264862 +0300
Change: 2016-11-23 20:15:30.261264862 +0300
Code: Select all
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
skip-external-locking
key_buffer_size = 16K
max_allowed_packet = 1M
table_open_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K
skip-innodb
default-storage-engine=MyISAM
#innodb_use_native_aio = 0
#innodb_file_per_table
max_connections=50
max_user_connections=25
wait_timeout=3660
interactive_timeout=50
long_query_time=5
#slow_query_log=1
#slow_query_log_file=/var/log/mysql-slow-queries.log
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
Но как я понимаю проблема у многих, просто не все смотрят графики, сервер доходит до максимума памяти и продолжает работать, сайты не вырубаются, а апдейт только произошел, не все даже поняли что он был, если включен автоапдейт, как назло был включен ) хотя обычно выключаею, просто поставил систему 3 дня назад )))
Code: Select all
free -m
total used free shared buffers cached
498 317 181 26 28 227
-/+ buffers/cache: 61 437
Почему тогда графики рисуют по-новому, как я понимаю такое поведение в Linux обычно - вся память уходи под кеш?