14.07.2020 15:06
DMaslov
 
Выделить конкретные операции, при которых наблюдаются тормоза, кассир не может.
Бывает и при оплате, и при внесении товара в чек.
Логи Сбера, превысившие 1 ГБ, несколько дней назад почищены.
Что еще посмотреть?
fsck могу удаленно сделать без приглашения в магазин эникейщика?


Код:
-:
192.168.7.201#top top - 14:00:17 up 6:01, 1 user, load average: 0.03, 0.04, 0.05 Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie Cpu(s): 0.6%us, 0.3%sy, 0.0%ni, 99.0%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3008276k total, 1454860k used, 1553416k free, 176k buffers Swap: 240968k total, 336k used, 240632k free, 1210860k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4313 root 20 0 178m 156m 6364 S 2 5.3 0:14.27 mysqld 4266 ukmclien 20 0 227m 43m 35m S 1 1.5 0:49.32 ukmclient 4027 root 20 0 4084 1336 1200 S 0 0.0 0:29.14 pcscd 4302 root 20 0 178m 156m 6364 S 0 5.3 0:11.43 mysqld 9475 root 20 0 1992 1624 1388 R 0 0.1 0:00.08 top 1 root 20 0 1432 1104 1044 S 0 0.0 0:01.90 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0 0.0 0:00.51 ksoftirqd/0 4 root 20 0 0 0 0 S 0 0.0 0:00.00 kworker/0:0 5 root 0 -20 0 0 0 S 0 0.0 0:00.00 kworker/0:0H 7 root 20 0 0 0 0 S 0 0.0 0:01.25 rcu_preempt 8 root 20 0 0 0 0 S 0 0.0 0:00.00 rcu_sched 9 root 20 0 0 0 0 S 0 0.0 0:00.00 rcu_bh 192.168.7.201#ls -lh /usr/local/auth/sbrf/ total 67M -rw-rw-rw- 1 root root 1.5K Июл 13 18:59 00149888_inf.txt -rw-rw-rw- 1 root root 16M Июл 14 13:42 CommLog2.txt -rw-rw-rw- 1 root root 256 Июл 14 13:42 e -rw-rw-rw- 1 root root 21 Дек 22 2018 EMVM.D -rwxrwxrwx 1 root root 11K Апр 28 2017 F12X24.BIN -rw-rw-rw- 1 root root 300 Дек 22 2018 FF03.D -rw-rw-rw- 1 root root 159K Дек 22 2018 FF10.D -rw-rw-rw- 1 root root 8.0K Дек 22 2018 FF10.I -rw-rw-rw- 1 root root 67K Дек 22 2018 FF24.D -rw-rw-rw- 1 root root 8.0K Дек 22 2018 FF24.I -rw-rw-rw- 1 root root 43K Дек 22 2018 FF29.D -rw-rw-rw- 1 root root 8.0K Дек 22 2018 FF29.I -rwxrwxrwx 1 root root 42K Авг 13 2018 OPT0.R -rwxrwxrwx 1 root root 21K Авг 13 2018 OPT1.R -rwxrwxrwx 1 root root 1.8K Авг 13 2018 OPT3.R -rwxrwxrwx 1 root root 160 Авг 13 2018 OPT4.R -rw-rw-rw- 1 root root 1.5K Июл 14 13:42 p -rw-r--r-- 1 root root 193 Ноя 8 2018 pinpad.ini -rwxrwxrwx 1 root root 949K Авг 13 2018 posScheduler -rw-rw-rw- 1 root root 810 Дек 31 2018 posScheduler1812.log -rw-rw-rw- 1 root root 2.4K Янв 31 2019 posScheduler1901.log -rw-rw-rw- 1 root root 2.3K Фев 28 2019 posScheduler1902.log -rw-rw-rw- 1 root root 2.5K Мар 31 2019 posScheduler1903.log -rw-rw-rw- 1 root root 2.5K Апр 30 2019 posScheduler1904.log -rw-rw-rw- 1 root root 2.8K Май 31 2019 posScheduler1905.log -rw-rw-rw- 1 root root 2.8K Июн 30 2019 posScheduler1906.log -rw-rw-rw- 1 root root 3.6K Июл 31 2019 posScheduler1907.log -rw-rw-rw- 1 root root 3.3K Авг 31 2019 posScheduler1908.log -rw-rw-rw- 1 root root 2.9K Сен 30 2019 posScheduler1909.log -rw-rw-rw- 1 root root 2.6K Окт 31 2019 posScheduler1910.log -rw-rw-rw- 1 root root 2.5K Ноя 30 2019 posScheduler1911.log -rw-rw-rw- 1 root root 2.5K Дек 31 2019 posScheduler1912.log -rw-rw-rw- 1 root root 2.5K Янв 31 08:33 posScheduler2001.log -rw-rw-rw- 1 root root 2.6K Фев 29 00:00 posScheduler2002.log -rw-rw-rw- 1 root root 2.5K Мар 30 08:06 posScheduler2003.log -rw-rw-rw- 1 root root 1.9K Апр 30 09:13 posScheduler2004.log -rw-rw-rw- 1 root root 2.5K Май 31 09:08 posScheduler2005.log -rw-rw-rw- 1 root root 2.5K Июн 30 10:49 posScheduler2006.log -rw-rw-rw- 1 root root 1.1K Июл 14 08:37 posScheduler2007.log -rwxrwxrwx 1 root root 446 Апр 28 2017 printers.ini -rwxrwxrwx 1 root root 1.5M Авг 13 2018 sb_pilot -rwxr-xr-x 1 1000 1000 98 Окт 29 2018 sb_pilot_manual_run.sh -rwxrwxrwx 1 root root 1.2K Дек 22 2018 sbrfsetup.sh -rw-rw-rw- 1 root root 12 Июл 14 13:42 SESS.D -rw-rw-rw- 1 root root 798 Июл 14 13:42 SPLC.D -rwxr-xr-x 1 1000 1000 499 Окт 29 2018 ukm_runsbrf_in.sh -rwxr-xr-x 1 1000 1000 912 Окт 29 2018 ukm_runsbrf.sh -rwxr-xr-x 1 1000 1000 4.4K Окт 29 2018 ukm_sbrf_functions.sh -rw-rw-rw- 1 root root 39M Июл 14 13:42 ukmsbrf.log -rwxrwxrwx 1 root root 52K Дек 22 2018 ukm-sbrf.map -rwxrwxrwx 1 root root 380 Дек 22 2018 unicode_stop -rw-rw-rw- 1 root root 131K Дек 31 2018 upos1812.log -rw-rw-rw- 1 root root 237K Янв 31 2019 upos1901.log -rw-rw-rw- 1 root root 295K Фев 28 2019 upos1902.log -rw-rw-rw- 1 root root 371K Мар 31 2019 upos1903.log -rw-rw-rw- 1 root root 573K Апр 30 2019 upos1904.log -rw-rw-rw- 1 root root 643K Май 31 2019 upos1905.log -rw-rw-rw- 1 root root 544K Июн 30 2019 upos1906.log -rw-rw-rw- 1 root root 482K Июл 31 2019 upos1907.log -rw-rw-rw- 1 root root 381K Авг 31 2019 upos1908.log -rw-rw-rw- 1 root root 422K Сен 30 2019 upos1909.log -rw-rw-rw- 1 root root 433K Окт 31 2019 upos1910.log -rw-rw-rw- 1 root root 417K Ноя 30 2019 upos1911.log -rw-rw-rw- 1 root root 449K Дек 31 2019 upos1912.log -rw-rw-rw- 1 root root 327K Янв 31 18:59 upos2001.log -rw-rw-rw- 1 root root 346K Фев 29 18:00 upos2002.log -rw-rw-rw- 1 root root 472K Мар 30 14:04 upos2003.log -rw-rw-rw- 1 root root 462K Апр 30 17:01 upos2004.log -rw-rw-rw- 1 root root 862K Май 31 16:02 upos2005.log -rw-rw-rw- 1 root root 828K Июн 30 18:58 upos2006.log -rw-rw-rw- 1 root root 311K Июл 14 13:42 upos2007.log 192.168.7.201#df -h Filesystem Size Used Avail Use% Mounted on LABEL=rootpart 56G 6.8G 49G 13% / /dev/sda1 30M 7.2M 21M 26% /boot none 1.5G 0 1.5G 0% /dev/shm 192.168.7.201#service ukmclient stop 192.168.7.201#service mysql stop Shutting down MySQL.. [ OK ] 192.168.7.201#mount LABEL=rootpart on / type btrfs (rw) none on /proc type proc (rw) /dev/sda1 on /boot type ext3 (rw,data=journal) none on /dev/shm type tmpfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) 192.168.7.201#umount /dev/sda1 192.168.7.201# fsck -a /dev/sda1 fsck 1.41.4 (27-Jan-2009) bootpart: clean, 23/8032 files, 9385/32096 blocks (check in 5 mounts) 192.168.7.201# fsck -pc /dev/sda1 fsck 1.41.4 (27-Jan-2009) bootpart: Updating bad block inode. bootpart: 23/8032 files (13.0% non-contiguous), 9385/32096 blocks
14.07.2020 15:40
OlegON
 
я бы проверил, что на btrfs не включен autodefrag, а на файлах базы mysql выключен CoW. да и scrub бы btrfs сделал... журналы, опять же, надо посмотреть...
14.07.2020 16:16
OlegON
 
еще смущает своп при наличии большого количества свободной памяти... как будто что-то тяжелое запускалось и отработало...
15.07.2020 08:54
DMaslov
 
Особого криминала в журналах не увидел.

За 3 года использования УКМ4 каких-либо обслуживающих действий с кассами - дефрагментация и пр. - не делал.

Наблюдаем дальше.
Вложения
Тип файла: zip log.zip (12.50 Мб, 16 просмотров)
15.07.2020 09:19
OlegON
 
Ну, ничего особенного не вижу
Jul 14 15:09:31 localhost init_d_mysql: pid_file=/usr/local/mysql/var/mysqld.pid
Jul 14 15:09:31 localhost init_d_mysql: ERROR: WARNING! MySQL manager or server PID file could not be found!
это бы поправил в конфиге мускула, лучше будет, если система будет знать, какой PID у базы.

Еще что бросилось в глаза - обилие заббикса. Он работает или нет? На моей памяти было серьезное выжирание памяти агентом заббикса. Если не работает - лучше убить. Если работает - должна быть видна причина свопа. В общем и целом я именно бы копал в направлении заполненного свопа, посмотрел бы swappiness и поставил бы его в значение по умолчанию.

Все рекомендации данные во втором сообщении темы остаются в силе, независимо от того, делалось ли что-то раньше.
15.07.2020 09:30
~Guest~
 
OlegON, было время, хвосты заббикса Сервис Плюс клал по умолчанию. Была идея в этом направлении неплохая, но очевидно не прижилась.
15.07.2020 10:06
Iggy
 
А с диском все в порядке?
Столкнулся с тормозами на ChWay Light, через 2-3 года значение Load/unload cycle count достигало нескольких миллионов. Поиск товара или закрытие чека занимало до минуты. Сам диск вроде живой, но при попытке перезалить УКМ падает.
15.07.2020 10:23
~Guest~
 
Цитата:
Iggy А с диском все в порядке?
Столкнулся с тормозами на ChWay Light, через 2-3 года значение Load/unload cycle count достигало нескольких миллионов. Поиск товара или закрытие чека занимало до минуты. Сам диск вроде живой, но при попытке перезалить УКМ падает.
Вот только хотел написать, диск новый перекинуть, просто проверить, все ли хорошо.
16.07.2020 14:49
alektbk
 
если 88ые посы то там ssd "китайчиские" "разкетайчиские" Smartbuy столкнулись как то с проблемами такими, не оптимизации не проверки ребилды переливы итд надолго не спасали а спасало только одно покупка нового нормального ssd минимально даже зеленой WD на 120 гб на 77ых тоже самое но там обычные не ssd живут подольше
16.07.2020 15:05
~Guest~
 
alektbk, ладно сказки лить, мы не С+, но 4 года продаем Smartbuy в составе компов, нет на них нареканий, процент брака настолько минимальный, что мне кажется меньше чем у HDD. Хотя даже в интернете отзывы по Smartbuy читаешь и диву даешься, ну нет таких проблем, в противном случае давно бы перешли на другого производителя.

А вот с полностью китайскими бывают проблемы, в этом спора нет, в том числе и по факту несоответствия заявленных ТТХ.
Часовой пояс GMT +3, время: 16:10.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.