Page 3 of 11
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 5:38 pm
by Kirill
Вопрос к разработчикам!
Как же так, не обкатанную версию кинули в обновление. Это, что шутка такая?
Ну на доже хотя бы какую то ответственность иметь.
Ведь Ваш продукт выбирают за надежность и стабильность работы, а не за то, что он бесплатный.
Лично я не против того если VestaCP станет платная, но только если она будет стабильная и надежная.
Обкатали бы, потом выложили.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:14 pm
by 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 кушал - так и осталось. Как бы.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:18 pm
by Kirill
На пустом сервере RAM-512 (читая свежая установка) nginx+apache.
Что на CentOS. что на Debian - одинаковая картина.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:34 pm
by Stesh
Kirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.
Что на CentOS. что на Debian - одинаковая картина.
Покажи stat /etc/my.cnf
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:40 pm
by korvinod
Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:42 pm
by korvinod
Кстати, к разработчикам..
Было бы неплохо вывести список изменений. Что бы хоть знать что копать и в какую сторону :((
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:45 pm
by Kirill
Stesh wrote:Kirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.
Что на CentOS. что на Debian - одинаковая картина.
Покажи stat /etc/my.cnf
Вам, что самому лень.
Возьмите тестовый сервер, да установите VestaCP nginx+apache. Все увидите сами.
Сколько можно показывать? Не до показов уже (((.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 6:55 pm
by Stesh
korvinod wrote:Если у 10 из 11 юзеров проблема, то у одного - исключение.
Не наоборот.. правильно?
Все относительно. Ведь мало кто, у кого проблемы нет, рапортует об этом. Ну ладно, это риторика.
Есть проблема? Ок, давайте искать откуда. Речь про обновление на центосе, не чистая установка (при установке панель тянет свои конфиги, которые могут не всем подходить).
Mysql. За его работу отвечает /etc.cnf (и в нем инклуд на /etc/my.cnf.d/, который может использоваться, а может не использоваться). Для того, чтобы изменить работу mysql, нужно а) перезаписать этот файл б) перезапустить mysql.
Т.е. смотрим дату модификации файла + сколько работает mysql, при условии что не перегружалась система (насколько помню, он не перезапускается при обновлении). Если файл модифицировался, смотрим diff с бекапным файлов (ведь все делают бекапы), и бяка может вылезти.
И так далее.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 7:01 pm
by Stesh
Kirill wrote:Stesh wrote:Kirill wrote:На пустом сервере RAM-512 (читая свежая установка) nginx+apache.
Что на 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. Можно не показывать, дело добровольное.
Re: RAM после обновления до 17
Posted: Sat Nov 26, 2016 7:07 pm
by 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 обычно - вся память уходи под кеш?