When a WHO query is run through znc, for the entire time who responses are being received, ~5mbps of disk IO happens. It's not writing to the debug log, and it's almost certainly not the IRC logs generated by the log module.
ZNC version: 1.6.3
OS: Debian wheezy
When a WHO query is run through znc, for the entire time who responses are being received, ~5mbps of disk IO happens. It's not writing to the debug log, and it's almost certainly not the IRC logs generated by the log module.
ZNC version: 1.6.3
OS: Debian wheezy
##
<!-- github-sync-id:154534302 -->
It happens every time, and I have plenty of free ram. Swap I/O doesn't seem to be happening.
I haven't run strace yet, I'll see if I can reproduce and test it more on my local machine tomorrow or later.
It happens every time, and I have plenty of free ram. Swap I/O doesn't seem to be happening.
I haven't run strace yet, I'll see if I can reproduce and test it more on my local machine tomorrow or later.
<!-- github-comment-id:218910109 -->
The culprit seems to be an open("/data/znc/znc-data//users/RX14/networks/esper/moddata/clientbuffer/.registry", O_WRONLY|O_CREAT|O_TRUNC, 0600), followed by a crazy amount of write calls (15433 for a who on a channel with only 7 members).
Sorry, I forgot about this. Still happening:
```
<RX14> listmods
<*status> Global modules:
<*status> +===========+===========+
<*status> | Name | Arguments |
<*status> +===========+===========+
<*status> | webadmin | |
<*status> +-----------+-----------+
<*status> | adminlog | |
<*status> +-----------+-----------+
<*status> | certauth | |
<*status> +-----------+-----------+
<*status> | chansaver | |
<*status> +-----------+-----------+
<*status> | partyline | |
<*status> +-----------+-----------+
<*status> | identfile | |
<*status> +===========+===========+
<*status> User modules:
<*status> +==============+===========+
<*status> | Name | Arguments |
<*status> +==============+===========+
<*status> | cert | |
<*status> +--------------+-----------+
<*status> | chansaver | |
<*status> +--------------+-----------+
<*status> | clientnotify | |
<*status> +--------------+-----------+
<*status> | controlpanel | |
<*status> +--------------+-----------+
<*status> | log | |
<*status> +--------------+-----------+
<*status> | perform | |
<*status> +==============+===========+
<*status> Network modules:
<*status> +==============+===========+
<*status> | Name | Arguments |
<*status> +==============+===========+
<*status> | chansaver | |
<*status> +--------------+-----------+
<*status> | kickrejoin | |
<*status> +--------------+-----------+
<*status> | clientbuffer | autoadd |
<*status> +--------------+-----------+
<*status> | perform | |
<*status> +==============+===========+
```
Plenty of ram, `strace` shows this (who on a channel with 975 members):
```
$ strace -c -p 23199
Process 23199 attached - interrupt to quit
^CProcess 23199 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
97.04 0.028303 0 584939 write
1.40 0.000407 2 247 16 open
1.03 0.000300 1 231 close
0.42 0.000122 1 149 poll
0.07 0.000020 0 56 munmap
0.05 0.000015 0 477 read
0.00 0.000000 0 291 16 stat
0.00 0.000000 0 112 fstat
0.00 0.000000 0 56 lseek
0.00 0.000000 0 56 mmap
0.00 0.000000 0 350 fcntl
------ ----------- ----------- --------- --------- ----------------
100.00 0.029167 586964 32 total
```
The culprit seems to be an `open("/data/znc/znc-data//users/RX14/networks/esper/moddata/clientbuffer/.registry", O_WRONLY|O_CREAT|O_TRUNC, 0600)`, followed by a crazy amount of `write` calls (15433 for a who on a channel with only 7 members).
<!-- github-comment-id:260994345 -->
clientbuffer is an external module.
Looks like it writes that file on every message received from every client and sent to every client.
There's nothing upstream ZNC can do here.
clientbuffer is an external module.
Looks like it [writes](https://github.com/jpnurmi/znc-clientbuffer/blob/74f6b3893cd2bb3ca390f4eaa15dd1baeec41f8c/clientbuffer.cpp#L285) that file on every message received from every client and sent to every client.
There's nothing upstream ZNC can do here.
<!-- github-comment-id:261000116 -->
Sorry about that, it's been so long since I set up znc I forgot that clientbuffer was an external module, I'll report it over there.
Sorry about that, it's been so long since I set up znc I forgot that clientbuffer was an external module, I'll report it over there.
<!-- github-comment-id:261000666 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
When a WHO query is run through znc, for the entire time who responses are being received, ~5mbps of disk IO happens. It's not writing to the debug log, and it's almost certainly not the IRC logs generated by the log module.
ZNC version: 1.6.3
OS: Debian wheezy
Does it happen every time?
What does
stracesay?Can it be swapping because of low RAM?
It happens every time, and I have plenty of free ram. Swap I/O doesn't seem to be happening.
I haven't run strace yet, I'll see if I can reproduce and test it more on my local machine tomorrow or later.
Which modules are loaded? That might make a difference as well.
Just guessing http://wiki.znc.in/Aka_(nicktrace) .
If you have updates, reopen
Sorry, I forgot about this. Still happening:
Plenty of ram,
straceshows this (who on a channel with 975 members):The culprit seems to be an
open("/data/znc/znc-data//users/RX14/networks/esper/moddata/clientbuffer/.registry", O_WRONLY|O_CREAT|O_TRUNC, 0600), followed by a crazy amount ofwritecalls (15433 for a who on a channel with only 7 members).clientbuffer is an external module.
Looks like it writes that file on every message received from every client and sent to every client.
There's nothing upstream ZNC can do here.
Sorry about that, it's been so long since I set up znc I forgot that clientbuffer was an external module, I'll report it over there.