Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
+7 (495) 108-0-888 info@ubiquiti.ru
Каталог
+7 (499) 350-36-46 info@ubiquiti.ru
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Форумы: UniFi Protect, UniFi Network, UniFi Access, UniFi Talk, UniFi Drive, UniFi Mobility, UniFi Connect, UniFi Play, Wifiman, Feature-request, Site-manager, Edgemax, airfiber-ltu, unifi-led, unifi-voip, solar, security, link, aircontrol, unifi-video, new-to-unifi, ufiber, unms, Airfiber, Innerspace, ISP-design-center, Airmax, UISP-app, UID, 60GHz, General
Поиск  Пользователи  Правила  Войти
Страницы: 1
RSS
kevent 2: можно, чтобы кто-нибудь на это глянул?, UniFi Protect
 
#1
16.10.2023 21:40:00
Похоже, вы не приложили текст для перевода. Пожалуйста, отправьте текст, который нужно перевести на русский язык.
 
 
 
#2
16.06.2024 06:00:00
Несколько статистик по zswap:
# grep -R . /sys/kernel/debug/zswap
/sys/kernel/debug/zswap/stored_pages:35605
/sys/kernel/debug/zswap/pool_total_size:85983232
/sys/kernel/debug/zswap/duplicate_entry:0
/sys/kernel/debug/zswap/written_back_pages:2975212
/sys/kernel/debug/zswap/reject_compress_poor:635149
/sys/kernel/debug/zswap/reject_kmemcache_fail:0
/sys/kernel/debug/zswap/reject_alloc_fail:3880
/sys/kernel/debug/zswap/reject_reclaim_fail:76675
/sys/kernel/debug/zswap/pool_limit_hit:1929523

А как насчёт попробовать с отключённым zswap (если только исправление для kevent 2 не полностью зависит от zswap, что, может быть, не лучшее решение, учитывая, что zswap тоже может глючить на этом ядре 3.18.44)? Команда RPi решила свои проблемы с kevent 2 без использования zswap, так что, надеюсь, между ними нет зависимости...
 
 
 
#3
16.06.2024 05:43:00
None
 
 
 
#4
16.06.2024 00:32:00
01:25, сброса нет, но все камеры переподключились, и свободная память почти на пределе (так же, как и в 00:25). Интересно. Похоже, что всё продолжается по тому же часовому циклу, что и раньше, но почему-то сброс происходит не каждый раз — я предполагаю, что он срабатывает только тогда, когда свободной памяти в xx:25 становится меньше определённого порога. 🤷‍♂️
 
 
 
#5
15.06.2024 23:21:00
Ещё одно ядро, связанное с ax88179, сбросилось в 00:00:59 — чуть раньше, чем ожидалось. Лично я, учитывая регулярность предыдущих сбоев и этот сброс ровно в полночь, подозреваю, что есть какие-то фоновые службы на таймере, которые как-то жрут всю память и вызывают сброс. Мы уже наблюдали резкий рост сообщений «Starting direct reclaim...» за последние несколько дней — возможно, это связано.
 
 
 
#6
15.06.2024 22:02:00
И все сбои ядра происходят именно в драйвере ax88179 usbnet, конкретно в rx, с чего и началась эта тема... значит, какие бы изменения ни были в этом новом билде, похоже, они только усугубили проблему в разы...  
# grep ax88179 /var/log/kern.log  
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:40+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T20:24:50+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:49+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:51+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T21:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:34+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
2024-06-15T22:24:52+01:00 Cloud-Key-Plus kernel: [<ffffffc0004d730c>] ax88179_rx_fixup+0x118/0x1f8
 
 
 
#7
15.06.2024 21:49:00
Вот ситуация с памятью в 20:24: И снова в 21:24 И снова в 22:24 Меня не было дома, когда это всё происходило, я просто начал получать кучу писем в 20:25/21:25/22:25 с сообщениями, что все мои 5 камер снова подключились. Посмотрим, что будет в 23:24.
 
 
 
#8
15.06.2024 12:07:00
Вижу печальную тенденцию... [root@Cloud-Key-Plus 13:06] ~
# grep "Starting direct reclaim" /var/log/kern.log | cut -b1-10 | uniq -c  
  141 2024-06-09  
   68 2024-06-10  
 2394 2024-06-11  
 5928 2024-06-12  
99806 2024-06-13  
110211 2024-06-14  
46165 2024-06-15 (на 13:15)
 
 
 
#9
14.06.2024 11:51:00
Что запускает процесс:

Jun 14 12:49:23 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: try_to_free_pages: 31 вызовов подавлено  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:29 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:32 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: try_to_free_pages: 26 вызовов подавлено  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...  
Jun 14 12:49:38 Cloud-Key-Plus kernel: Начинается прямое освобождение памяти...

Цифры уже сводят с ума...  
[root@Cloud-Key-Plus 12:48] ~
# grep "Starting direct reclaim" /var/log/kern.log | cut -b1-10 | uniq -c  
  141 2024-06-09  
   68 2024-06-10  
 2394 2024-06-11  
 5928 2024-06-12  
99806 2024-06-13  
60485 2024-06-14  

Фрагментация Buddyinfo по-прежнему высокая, так что непонятно, что именно освобождается:  
2024-06-14 12:47:39 Node 0, zone     DMA  17831    447     71     12     13      5      1      1      0      0      0  
2024-06-14 12:48:09 Node 0, zone     DMA  15527    298     52     11     13      5      1      1      0      0      0  
2024-06-14 12:48:39 Node 0, zone     DMA  17557    329     47     18     13      5      1      1      0      0      0  
2024-06-14 12:49:09 Node 0, zone     DMA  16466    492     42      9     11      5      1      1      0      0      0  
2024-06-14 12:49:39 Node 0, zone     DMA  16592    501     44      7     10      5      1      1      0      0      0
 
 
 
#10
13.06.2024 09:45:00
Краткое обновление — сообщения о reclaim, похоже, усиливаются...[root@Cloud-Key-Plus 10:40] ~
# grep "Starting direct reclaim" /var/log/kern.log | cut -b1-10 | uniq -c  
  141 2024-06-09  
   68 2024-06-10  
 2394 2024-06-11  
 5928 2024-06-12  
37412 2024-06-13  
Текущая информация buddyinfo... явных улучшений нет:  
2024-06-13 10:33:27 Node 0, zone     DMA  12415    400     40      3      8      6      2      1      0      0      0  
2024-06-13 10:33:57 Node 0, zone     DMA  11937    298     24     10      8      6      2      1      0      0      0  
2024-06-13 10:34:27 Node 0, zone     DMA  12142    351     43     11      8      6      2      1      0      0      0  
2024-06-13 10:34:57 Node 0, zone     DMA  11931    470     64     10      9      6      2      1      0      0      0  
2024-06-13 10:35:27 Node 0, zone     DMA  12874    397     33      9      8      6      2      1      0      0      0  
2024-06-13 10:35:57 Node 0, zone     DMA  12617    273     16      4      8      6      2      1      0      0      0  
2024-06-13 10:36:27 Node 0, zone     DMA  12077    307     34     10     10      6      2      1      0      0      0  
2024-06-13 10:36:57 Node 0, zone     DMA  12026    412     27      6     10      6      2      1      0      0      0  
2024-06-13 10:37:28 Node 0, zone     DMA  12425    349     35      8     10      6      2      1      0      0      0  
2024-06-13 10:37:58 Node 0, zone     DMA  11756    342     27      5      8      6      2      1      0      0      0  
2024-06-13 10:38:28 Node 0, zone     DMA  13114    425     26      7      6      6      2      1      0      0      0  
2024-06-13 10:38:58 Node 0, zone     DMA  13065    413     35      5      4      6      2      1      0      0      0  
2024-06-13 10:39:28 Node 0, zone     DMA  13238    667     37      3      3      6      2      1      0      0      0  
2024-06-13 10:39:58 Node 0, zone     DMA  13422    391     19      6      2      5      2      1      0      0      0  
2024-06-13 10:40:28 Node 0, zone     DMA  13769    517     40      8      5      5      2      1      0      0      0  
и свободная память (выглядит нормально):  
Jun 13 10:41:08 Cloud-Key-Plus earlyoom[2999]: mem avail: 1046 of 2980 MiB (35.11%), swap free: 5578 of 6142 MiB (90.80%)
Честно говоря, не очень понятно, что именно тут «reclaimed»... \o/
 
 
 
#11
13.06.2024 00:08:00
Спасибо, @UI-Team. Подумаю об этом сегодня ночью, но, скорее всего, соглашусь на замену UCKG2+ (замена на другой UCKG2+), так как, думаю, мы не сможем двигаться дальше, если вы не сможете воспроизвести проблему и останется хоть малейшее подозрение на аппаратный сбой (хотя я сам в это сомневаюсь, но, наверное, нужно исключить этот вариант).

Тем временем заметил, что в новой сборке 3.2.18-root.15193 в системном логе за день появляется около 6000 записей следующего рода — пока не ясно, что их вызывает и какая от этого польза (ничего очевидного я не вижу):

Jun 13 00:57:51 Cloud-Key-Plus kernel: try_to_free_pages: 25 callbacks suppressed  
Jun 13 00:57:51 Cloud-Key-Plus kernel: Starting direct reclaim...  
(repeated multiple times)

Новый файл поддержки во вложении: support-C889-1718236546259-v3.2.18-root.15193-reclaim-loop.tgz
 
 
 
#12
12.06.2024 20:25:00
@NeilM-KCC Спасибо, что заметили и сообщили. Это, конечно, неожиданно — наша команда разработчиков сейчас пытается воспроизвести проблему, но на данный момент других известных случаев именно с этим багом у нас нет. В связи с этим мы готовы заменить ваш Cloud Key на новый или на NVR, если хотите. Это также поможет нам в анализе отказов и ускорит поиск решения. Я напишу вам в личку, чтобы оформить замену.
 
 
 
#13
12.06.2024 16:20:00
Пожалуй, стоит обновиться с Protect 4.0.31 до 4.0.33, раз версия 4.0.31 уже упала. Я пытаюсь держать процессы работающими как можно дольше, чтобы наблюдать долгосрочное поведение системы (особенно ядра), но с этими нестабильными тестовыми сборками это становится невозможным.  
P.S. Еще обновлю UNA с 8.1.122 до 8.2.93 — раз уж взялся, так до конца...
 
 
 
#14
02.10.2024 15:30:00
Прошло очень много времени с последнего обновления, но прогресс есть! Я отправил на RMA свой оригинальный UCKG2+ с тестовой сборкой 4.0.6, так как он показывал всевозможные странные ошибки памяти — не только kevent 2, но и ошибки выделения страниц ядра, сбои выделения памяти Java GC, процессы, которые бросали SIGABT и так далее. Возможно, из-за неисправной оперативной памяти. Пришел новый UCKG2+, который я тестирую с штатным HDD (а не с моим оригинальным 1ТБ SSD).

Я начал снова с той же тестовой сборки 4.0.6, и она вроде бы работает лучше, хотя всё ещё возникали ошибки systemd "Watchdog Timeout", из-за которых процессы (UNA, Protect) перезапускались принудительно, обычно примерно раз в неделю. Эта проблема сохраняется до сих пор.

Сейчас я уже 68 дней работаю на версии 4.0.12 GA. К этому времени я бы уже увидел кучу ошибок kevent 2 (миллионы в день), но пока ни одной ошибки, и /proc/buddyinfo тоже выглядит намного лучше, так что надеюсь, что исходная проблема с kevent 2, о которой шла речь в этой теме, наконец решена (точнее, в прошивке 4.0.3).

Однако ошибки Watchdog Timeout всё ещё появляются, но скорее всего это уже другая проблема.

Огромное спасибо Amon за всю поддержку. 👍

Следующие шаги (возможно, скоро):

• Поставить новый 1ТБ Crucial MX500 SSD? Новый UCKG2+ с обычным 1ТБ HDD действительно сильно греется, и я заметил ограничение производительности из-за нагрева, когда процессор прогрелся до 70°С на прошивке 4.0.12, хотя сам UCKG2+ стоит на деревянной полке (на резиновых прокладках) в шкафу с кучей свободного места вокруг.

• Обновиться до последней прошивки 4.0.20, UNA 8.5.5, Protect 5.0.34, камеры 4.72.36 — может быть, на следующей неделе...
 
 
 
#15
26.06.2024 13:52:00
Обновление для всех, так как за последние пару месяцев мне написали несколько участников форума, что следят за этой темой с интересом (огромное спасибо!). 👍 В среду, 19 июня 2024, у меня была очень конструктивная беседа со службой поддержки вне форума (благодарю всех причастных!), и мы договорились о следующем плане (к которому я только сейчас приступаю, так как был несколько дней вне):

- RMA поставили на паузу  
- Я отменил изменение zswap PRIORITY=1500 (вернул на 500)  
- Только что обновился с UniFi 3.2.18-root.15193 до UniFi 4.0.6 (RC), так как UniFi 4.0.3 (EA) содержит исправление для kevent 2 (хотя это и не явно указано в списке изменений, мне сказали, что оно там есть! 👍) — пока всё идет отлично... 🙂  

Мы договорились: если проблема с kevent 2 повторится или процессы будут продолжать падать, тогда я сделаю сброс UCKG2+ к заводским настройкам и восстановлю последнюю резервную копию.  

Если проблемы останутся даже после сброса и восстановления, тогда будем обсуждать дальнейшие шаги (сначала через систему тикетов).  

Держим пальцы крестиком! 👍  

UCKG2+ сейчас работает на самой последней и актуальной версии:  
- UniFi 4.0.6 (RC)  
- UNA 8.3.20 (EA)  
- Protect 4.0.33 (GA) с прошивкой камеры 4.71.110 (EA) (5 штук G3 Instant)  

@UI-Glenn Пока меня не было, с выходных до утренних часов вторника случилось несколько падений, поэтому для полноты прикрепляю финальный файл поддержки для 3.2.18:  
support-C889-1719407116337-v3.2.18-root.15193-final.tgz
 
 
 
#16
16.06.2024 09:58:00
None
 
 
 
#17
16.06.2024 06:44:00
В 07:25 не было замечено никаких проблем с повторным подключением камер или исчерпанием памяти. Возможно, это связано с тем, что сервис Protect перезапустился в 06:25 и очистил ту самую проблему, которая вызывала исчерпание памяти и сбои ядра последние 10–12 часов. Сейчас система выглядит более-менее «нормальной» (что вообще значит «нормальная» для этой системы!). Если что-то изменится, я сообщу.
 
 
 
Страницы: 1
Читают тему (гостей: 1)