Lsof и datapacket.com это баг или провокация?

Node Operators troubleshooting
,
21

Ну если с клиентами контракты подпишут, то такая же загрузка будет и на продакшн сателлитах.
А так - способ выявить и исправить узкие места до того, как эти клиенты датапушки направят.

22

ну сейчас у меня с солтлейка 50Тиб, что более половины всего обьема. Хотя оплата с этих терабайтов никакущаа конечно

сателиты независимы, так что если бы можно было набить, оно бы набилось. Свободное место у меня всегда есть, дисков на полпета.

image
новый рекорд

23

Информацию о найденном расхождении по сокетам команде передал, пока тишина.

24

Можете, пожалуйста, показать несколько строк результата команды:

lsof -nP -p $NODE_PID
25 
# lsof -nP -p 25988 | wc -l
1216
# lsof -n | grep 25988 | wc -l
829779

# lsof -nP -p 25988 | tail
storageno 25988 root 1612u     IPv6          342672291        0t0       TCP 192.168.156.4:4314->79.127.205.241:53252 (ESTABLISHED)
storageno 25988 root 1623u     IPv6          342672293        0t0       TCP 192.168.156.4:4314->79.127.205.238:46104 (ESTABLISHED)
storageno 25988 root 1631u     IPv6          342673547        0t0       TCP 192.168.156.4:4314->109.61.92.67:59730 (ESTABLISHED)
storageno 25988 root 1638u     IPv6          342697105        0t0       TCP 192.168.156.4:4314->79.127.205.230:49222 (ESTABLISHED)
storageno 25988 root 1649u     IPv6          342644818        0t0       TCP 192.168.156.4:4314->79.127.219.35:58368 (ESTABLISHED)
storageno 25988 root 1655u     IPv6          342865454        0t0       TCP 192.168.156.4:4314->109.61.92.74:60386 (ESTABLISHED)
storageno 25988 root 1661u     IPv6          342769356        0t0       TCP 192.168.156.4:4314->79.127.201.213:41262 (ESTABLISHED)
storageno 25988 root 1664u     IPv6          342769354        0t0       TCP 192.168.156.4:4314->79.127.201.209:43478 (ESTABLISHED)
storageno 25988 root 1673u     IPv6          342941806        0t0       TCP 192.168.156.4:4314->79.127.219.39:37974 (ESTABLISHED)
storageno 25988 root 1676u     IPv6          342933321        0t0       TCP 192.168.156.4:4314->109.61.92.83:43484 (ESTABLISHED)
2 Likes
26

Похоже, что баги нет.

1 Like
27

ага, а остальные 800000+ просто для запасу висят в процессе.
Не буду я ваш корявый код смотреть, нет баги так нет. Научитесь программировать, отпишитесь тут.
Или админить ресурсы хотя бы. Попробуйте умозрительно сопоставить количество потоков на моей домашней тачке с количеством 800 тысяч…
Я еще раз намекаю - эти 800000+ чьи-то потерянные дескрипторы (коннектов или держащих их давно законченных потоков), которые процесс storagenode не дает ОС освободить окончательно, по причине потеряных ссылок, неправильного освобождения (Dispose) или проблем с каким нить сборщиком мусора (GAC или аналоги) итд… итп…
Эти незакрытые хэндлы - это считанный ресурс ОС, и будьте уверены, что на вашей стороне эта или подобная ошибка гораздо серьезнее может влиять на перфоманс, чем на моей домашней тачке.

28

Спасибо за советы. Обязательно передам.

29

A response for posterity, since I assume this abusive person is already gone:

There are not 800000+ open file handles in that process.

There are 1216 open file handles, and somewhere around 600-700 separate threads.

If you do not specify the -p option, the lsof tool will print one line for every open file handle for every task (thread) in the process. From the man page:

In general threads and tasks inherit the files of the caller, but may close some and open others, so
lsof always reports all the open files of threads and tasks.

You could verify this if you look at the output of lsof -n | grep 25988. You would find that the same set of ~1216 file handles are shown for each separate task ID (or nearly the same, as the set of open file handles probably changes over the time that lsof is collecting data). You could also try lsof -Ki, which suppresses the extra repeating of file handles for tasks.

1 Like
30

Duplicated for each thread. Thanks for the clarification

1 Like