[ZBX-18573] Performance of zabbix agent while scanning dir much worse than standard dir on Windows Created: 2020 Oct 28  Updated: 2024 Apr 10  Resolved: 2022 Aug 16

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G)
Affects Version/s: 5.0.6rc1
Fix Version/s: 5.0.27rc1, 6.0.8rc1, 6.2.2rc1, 6.4.0alpha1, 6.4 (plan)

Type: Problem report Priority: Critical
Reporter: Andrei Gushchin (Inactive) Assignee: Dmitrijs Goloscapovs (Inactive)
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ZBX-18573.patch     PNG File image-2022-07-08-15-10-36-114.png     PNG File screenshot-1.png     PNG File screenshot-2.png    
Issue Links:
Duplicate
Team: Team A
Sprint: Sprint 69 (Oct 2020), Sprint 70 (Nov 2020), Sprint 71 (Dec 2020), Sprint 72 (Jan 2021), Sprint 73 (Feb 2021), Sprint 74 (Mar 2021), Sprint 75 (Apr 2021), Sprint 76 (May 2021), Sprint 77 (Jun 2021), Sprint 78 (Jul 2021), Sprint 79 (Aug 2021), Sprint 80 (Sep 2021), Sprint 81 (Oct 2021), Sprint 82 (Nov 2021), Sprint 83 (Dec 2021), Sprint 84 (Jan 2022), Sprint 85 (Feb 2022), Sprint 86 (Mar 2022), Sprint 87 (Apr 2022), Sprint 88 (May 2022), Sprint 89 (Jun 2022), Sprint 90 (Jul 2022), Sprint 91 (Aug 2022)
Story Points: 2

 Description   

Steps to reproduce:
There is some folder with 65K empty files.
You want to count them.

Result:

.\zabbix_get.exe -s 127.0.0.1 -k 'vfs.dir.count[C:\DATA\tmp,.txt,,file]'
ZBX_NOTSUPPORTED: Timeout while waiting for data.

Always reached timeout event 30 sec., while dir /s /w return all file list and their count and size with 19-20 sec. or less

C:\DATA\tmp> dir /s /w
.....
test9984.txt         test9985.txt         test9986.txt         test9987.txt         test9988.txt         test9989.txt         test999.txt
test9990.txt         test9991.txt         test9992.txt         test9993.txt         test9994.txt         test9995.txt         test9996.txt
test9997.txt         test9998.txt         test9999.txt         test[1..60000].txt
           68064 File(s)              0 bytes

     Total Files Listed:
           68064 File(s)              0 bytes
               2 Dir(s)  31 752 388 608 bytes free

Expected:
Similar to native dir command perfomance.

 Comments   
Comment by Viktors Tjarve [ 2020 Nov 10 ]

There are 4 types of links in Windows platform:

link type create in cmd.exe
file symbolic link mklink Link Target
directory symbolic link mklink /D Link Target
file hard link mklink /H Link Target
directory hard link ( junction) mklink /J Link Target

Currently in Zabbix documentation for vfs.dir.count[] it is stated that

Pseudo-directories “.” and “..” are never counted.

Symbolic links are never followed for directory traversal.

On Windows, directory symlinks are skipped and hard links are counted only once.

Lets create a directory that contains three of each type links. All six file links point to the same file and all six directory links point to the same directory.
Then lets check the count of files and directories with cmd.exe dir, MS File Explorer and Zabbix agent and then check the count each time after deleting 1 of each type links.

How to create a symbolic link on Windows.

Observed:

  beginning -1 dir hard link -1 dir sym link -1 file hard link -1file sym link
cmd.exe dir file:6 dir:8 file:6 dir:7 file:6 dir:6 file:5 dir:6 file:4 dir:6
MS File Explorer file:6 dir:0 file:6 dir:0 file:6 dir:0 file:5 dir:0 file:4 dir:0
Zabbix agent file:4 dir:0 file:4 dir:0 file:4 dir:0 file:4 dir:0 file:3 dir:0

From this it is visible that:

  • cmd.exe dir shows every change;
  • MS File Explorer ignores all directory link changes but show all individual file link changes;
  • Zabbix agent ignores all directory link changes. There are no file hard link changes because two more file hard links pointing to the same file still exist. If all of them would be deleted then file count would decrease by 1. And all file symbolic link changes are shown.

Zabbix agent behaviuor matches what is stated in documentation but it is unclear why file hard links are counted only once for each target file. That is also the cause of the poor performance then a directory with large number of files has to be check with vfs.dir.count[]. Link information has to be extracted for every file that is counted to see if it's not a hard link to a target that already has been counted added to the total count before.
Also in multiple places in code there are comments that explain design decisions made to match MS File Explorer behaviour but counting file hard links differ when compared MS File Explorer to Zabbix agent.

Solution: For Windows Zabbix agent add additional type for types_incl parameter. It could be called "fhl" (file hard link). This type would not be included with type "all"(ZBX_FT_ALLMASK). If type "fhl" is used then all file hard links would be counted in as regular files same that is done by MS File Explorer. Now already file symbolic links are counted as regular files by both MS File Explorer and Zabbix agent.

Comment by Vladislavs Sokurenko [ 2022 Jul 05 ]

The problem is that there are additional system calls when using Zabbix agent instead of dir, it should be possible to avoid those system calls and to provide same functionality as dir provides.

<dgoloscapov> Agent is implemented in a way that vfs.dir.count counts hard links only once. It opens file handle to verify if this is file or hard link. It is the real reason why performance can be hit.  WinAPI doesn't seem to have any other way to check if some file is hard link, and how many times inode was linked.

Comment by Alex Kalimulin [ 2022 Jul 14 ]

We will remove the obscure feature of counting hard links only once on Windows. Also we should check how vfs.dir.get deals with hard links.

Comment by Dmitrijs Goloscapovs (Inactive) [ 2022 Aug 11 ]

Available in versions:

Documentation updated:

Generated at Sat Apr 04 14:19:30 EEST 2026 using Jira 10.3.13#10030013-sha1:56dd970ae30ebfeda3a697d25be1f6388b68a422.