RAM после обновления до 17

[Kirill]

Вопрос к разработчикам!

Как же так, не обкатанную версию кинули в обновление. Это, что шутка такая?
Ну на доже хотя бы какую то ответственность иметь.
Ведь Ваш продукт выбирают за надежность и стабильность работы, а не за то, что он бесплатный.
Лично я не против того если VestaCP станет платная, но только если она будет стабильная и надежная.

Обкатали бы, потом выложили.

[Stesh]

Пробежался по паре серверов, топ по памяти

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

Как бы все адекватно ситуации. У кого проблема - расковыривайте топ, смотрите что жрет память, дальше уже смотрите почему. У меня системные файлы (/etc/my.cnf, /etc/exim/exim.conf и прочее) обновление не тронуло, т.к. как мускул кушал, так он и кушает, как php-fpm кушал - так и осталось. Как бы.

[Kirill]

На пустом сервере RAM-512 (читая свежая установка) nginx+apache.

Code: Select all

MySQL = 2035 мб

Что на CentOS. что на Debian - одинаковая картина.

[Stesh]

На пустом сервере RAM-512 (читая свежая установка) nginx+apache.

Code: Select all

MySQL = 2035 мб

Что на CentOS. что на Debian - одинаковая картина.

Покажи stat /etc/my.cnf

[korvinod]

Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?

[korvinod]

Кстати, к разработчикам..
Было бы неплохо вывести список изменений. Что бы хоть знать что копать и в какую сторону :((

[Kirill]

На пустом сервере RAM-512 (читая свежая установка) nginx+apache.

Code: Select all

MySQL = 2035 мб

Что на CentOS. что на Debian - одинаковая картина.

Покажи stat /etc/my.cnf

Вам, что самому лень.
Возьмите тестовый сервер, да установите VestaCP nginx+apache. Все увидите сами.
Сколько можно показывать? Не до показов уже (((.

[Stesh]

Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?

Все относительно. Ведь мало кто, у кого проблемы нет, рапортует об этом. Ну ладно, это риторика.

Есть проблема? Ок, давайте искать откуда. Речь про обновление на центосе, не чистая установка (при установке панель тянет свои конфиги, которые могут не всем подходить).

Mysql. За его работу отвечает /etc.cnf (и в нем инклуд на /etc/my.cnf.d/, который может использоваться, а может не использоваться). Для того, чтобы изменить работу mysql, нужно а) перезаписать этот файл б) перезапустить mysql.
Т.е. смотрим дату модификации файла + сколько работает mysql, при условии что не перегружалась система (насколько помню, он не перезапускается при обновлении). Если файл модифицировался, смотрим diff с бекапным файлов (ведь все делают бекапы), и бяка может вылезти.

И так далее.

[Stesh]

На пустом сервере RAM-512 (читая свежая установка) nginx+apache.

Code: Select all

MySQL = 2035 мб

Что на CentOS. что на Debian - одинаковая картина.

Покажи stat /etc/my.cnf

Вам, что самому лень.
Возьмите тестовый сервер, да установите VestaCP nginx+apache. Все увидите сами.
Сколько можно показывать? Не до показов уже (((.

1. Мне не лень, но у меня проблемы нет, файл не модифировался (на примере mysql)

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

2. Не имею представления что там при установке, у ТС (и у других) пробема с обновлением. Обновление - когда ставится поверх 16-й 17-я версия штатно, через панель или yum update. 17-ю я еще не ставил с нуля, но предполагаю что как обычно, поставить и залить свои системные конфиги - и работа не будет отличаться от 16. Но на чистую я буду ставить чуть позднее.

3. Можно не показывать, дело добровольное.

[aysergeev]

результат stat

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

мускул модифицировался, conf.d пустой, обновлял до php7

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

-/+ buffers/cache used 61 - означает что занято только 61, это изменение поведения кеша в системе возможно?

Почему тогда графики рисуют по-новому, как я понимаю такое поведение в Linux обычно - вся память уходи под кеш?