Usually you need to do a few iterations on the strace data to get to the bottom of things.in strace.log: [pid 8088] 12:55:39.739539 poll([{fd=435, events=POLLOUT}], 1, 1800000 <unfinished ...> [pid 8058] 12:55:39.739573 <... write resumed> ) = 1 <0.000087> [pid 8088] 12:55:39.739723 <... poll resumed> ) = 1 ([{fd=435, revents=POLLOUT}]) <0.000168> [pid 8058] 12:55:39.739754 write(426, "dn: cn=ntU"..., 344 <unfinished ...> [pid 8088] 12:55:39.739824 sendto(435, "0<\2\1\2d7\0043u"..., 62, 0, NULL, 0 <unfinished ...> I took a look at the full file you uploaded. Couple of things : 1. With a truncated strace it helps to know the identity of the FDs. You can use "lsof" or dump the data out of /proc /sys...somewhere. 2. You can tell strace to only output certain classes of syscalls. For this problem, where filesystem I/O is the target, you can use : strace -e trace=file and -e trace=desc. More details here : https://linux-audit.com/the-ultimate-strace-cheat-sheet/ and also in the man page. This will remove the extra noise (gettimeofday() etc) in the output. That said, I saw this, which looks possibly like a smoking gun: [pid 8058] 12:55:40.563393 open("/etc/dirsrv/slapd-ldap0/dse.ldif.tmp", O_RDWR|O_CREAT|O_TRUNC, 0600 <unfinished ...> [pid 3186] 12:55:40.563826 <... select resumed> ) = 0 (Timeout) <0.009394> [pid 8058] 12:55:40.563855 <... open resumed> ) = 426 <0.000431> It looks to have opened dse.ldif, then assuming that FD = 426 is from the open() call, it goes on to write a bunch of data to that file : [pid 8058] 12:55:40.567465 write(426, "dn: cn=mon"..., 413) = 413 <0.000209> [pid 8058] 12:55:40.567826 write(426, "\n", 1) = 1 <0.000356> [pid 8058] 12:55:40.568601 write(426, "dn: cn=cha"..., 318) = 318 <0.000058> [pid 8058] 12:55:40.568727 write(426, "\n", 1) = 1 <0.000045> [pid 8058] 12:55:40.568937 write(426, "dn: cn=enc"..., 321) = 321 <0.000042> [pid 8058] 12:55:40.569040 write(426, "\n", 1) = 1 <0.000041> [pid 8058] 12:55:40.569182 write(426, "dn: cn=fea"..., 100) = 100 <0.000042> [pid 8058] 12:55:40.569281 write(426, "\n", 1) = 1 <0.000040> [pid 8058] 12:55:40.569427 write(426, "dn: cn=kol"..., 409) = 409 <0.000042> [pid 8058] 12:55:40.569528 write(426, "\n", 1) = 1 <0.000041> dse.ldif is supposed to hold seldom-changing config data for the server. So...one theory is that something the server is doing, or you are unknowingly asking it to do, is causing dse.ldif to be re-written constantly. As you point out, the high filesystem I/O may not be the cause for the poor search performance, but certainly the server should not be constantly re-writing dse.ldif. |
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx/message/4GAY2YSXU34GG5AKNG5Z5KHOBQXSP3MC/