Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-22990

Threadpool : Optimize network/named pipe IO for Windows

Details

    Description

      The WSARecv() calls that we use for the notification about new queries from client, allow (and are typically used with) the output buffer, so whenever notification happens, you already have read off the data.

      So far we passed 0-sized buffer to WSARecv (which I think is not officially documented, but appears to always work). This emulates Unix-poll readiness notification, works fine, but can be much better optimized.

      For example, before the query starts, we currently we do WSARecv() at least 3 times - once to get completion/readiness notification ( receiving 0 bytes ), another time when the packet header is read (4 bytes buffer), and the rest of packet (depends on how length parsed from the header). Even if 2 later calls would normally read from the socket buffer, and return without wait , it is an unnecessarily expensive copying from winsock buffers into user buffers.

      These 3 WSARecv calls can be reduced to 1 , if we passed a buffer during network AIO, which is filled upon AIO completion.
      All of the above also applies to named pipes( ReadFile instead of WSARecv)

      Note that in sysbench point-select workload that runs in memory, reading user input with ReadFile(WSARecv) is the most expensive operation, measured at 12% with named pipes

      Attachments

        Activity

          wlad Vladislav Vaintroub added a comment - - edited

          Excerpt from profiler run on current 10.5 (sysbench in-memory) functions sorted by Self CPU.
          ReadFile() and WriteFile() come exclusively from named pipe IO here - no usual files are read, data is already fully in memory

          Function Name	Total CPU [unit, %]	Self CPU [unit, %]	Module
           + mysqld.exe (PID: 14704)	182098 (100,00 %)	0 (0,00 %)	mysqld.exe
          | - [External Call] ReadFile	23612 (12,97 %)	23612 (12,97 %)	KernelBase.dll
          | - [External Call] WriteFile	15935 (8,75 %)	15935 (8,75 %)	KernelBase.dll
          | - [External Code]	182061 (99,98 %)	13356 (7,33 %)	Multiple modules
          | - rec_get_offsets_func	5257 (2,89 %)	3593 (1,97 %)	server.dll
          | - page_cur_search_with_match	11231 (6,17 %)	3429 (1,88 %)	server.dll
          | - buf_page_get_low	4247 (2,33 %)	2804 (1,54 %)	server.dll
          | - [External Call] RtlEnterCriticalSection	1643 (0,90 %)	1643 (0,90 %)	ntdll.dll
          | - rec_init_offsets	1647 (0,90 %)	1636 (0,90 %)	server.dll
          | - make_join_statistics	41661 (22,88 %)	1513 (0,83 %)	server.dll
          | - btr_cur_search_to_nth_level_func	18195 (9,99 %)	1397 (0,77 %)	server.dll
          

          wlad Vladislav Vaintroub added a comment - - edited Excerpt from profiler run on current 10.5 (sysbench in-memory) functions sorted by Self CPU. ReadFile() and WriteFile() come exclusively from named pipe IO here - no usual files are read, data is already fully in memory Function Name Total CPU [unit, %] Self CPU [unit, %] Module + mysqld.exe (PID: 14704) 182098 (100,00 %) 0 (0,00 %) mysqld.exe | - [External Call] ReadFile 23612 (12,97 %) 23612 (12,97 %) KernelBase.dll | - [External Call] WriteFile 15935 (8,75 %) 15935 (8,75 %) KernelBase.dll | - [External Code] 182061 (99,98 %) 13356 (7,33 %) Multiple modules | - rec_get_offsets_func 5257 (2,89 %) 3593 (1,97 %) server.dll | - page_cur_search_with_match 11231 (6,17 %) 3429 (1,88 %) server.dll | - buf_page_get_low 4247 (2,33 %) 2804 (1,54 %) server.dll | - [External Call] RtlEnterCriticalSection 1643 (0,90 %) 1643 (0,90 %) ntdll.dll | - rec_init_offsets 1647 (0,90 %) 1636 (0,90 %) server.dll | - make_join_statistics 41661 (22,88 %) 1513 (0,83 %) server.dll | - btr_cur_search_to_nth_level_func 18195 (9,99 %) 1397 (0,77 %) server.dll

          People

            wlad Vladislav Vaintroub
            wlad Vladislav Vaintroub
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.