Strange behavior during saving chunk to disk

During experiments with Manticore Search I faced with strange behavior (use latest version on Windows with default settings).
I created rt index with rt_mem_limit=‘1Gb’ and one text field by the following command via mysql:
create table test_def(content text) rt_mem_limit=‘1G’;
My test inserts new records into this index in 10 threads via mysql connector.
When RAM chunk becomes full and saves into disk execution of new inserts stalls approximately on 9 minutes. And according to log saving of chunks to disk consumes these 9 minutes:
rt: index test_def: diskchunk 8(1), segments 32 saved in 530.809 sec
rt: index test_def: diskchunk 9(2), segments 32 saved in 528.586 sec
But actually chunk files are created by several seconds and then nothing happened to them (they are not changed). And no other disk I/O operations performed:

So what really happens with searchd process after saving chunk to files? What can be a reason of such behavior? Why it logs that all this time it saves chunk to disk?

maybe windows defender checks daemon?

Could you create reproducible example that we could check locally? As it is not clear what happens in your case.

I made an experiment with disabled real-time protection on Windows Defender and results are the same.

As I mentioned earlier I created index by the following command:
create table test_def(content text) rt_mem_limit=‘1Gb’;
My test app is .Net Core console app using MySqlConnector to connect to manticore: NuGet Gallery | MySqlConnector 2.2.5

Test app starts 10 threads executing method that looks like the following:

public static void TestInsert()
{
  using (var connection = new MySqlConnection("server=localhost;port=9306;pooling=true;connection reset=false;connection timeout=1000;default command timeout=1000;"))
  {
    connection.Open();
    for (int i = 0; i < 1000; i++)
    {
      foreach (var content in _testData)
      {
        try
        {
          using (var insertCommand = new MySqlCommand {CommandText = "insert into test_def (content) values(@content)"})
          {
            insertCommand.Connection = connection;
            var parameter = new MySqlParameter("content", MySqlDbType.Text);
            parameter.Value = content;
            insertCommand.Parameters.Add(parameter);
            insertCommand.ExecuteNonQuery();
          }
        }
        catch (Exception e)
        {
          Console.WriteLine(e);
          throw e;
        }
      }
    }
  }
}

So each thread executes 1000 iterations of inserting of 300 texts with average length 4.000 symbols.

It could be better to provide complete example that I could issue locally or a docker file.

Below is the full text of simple test app (C# .Net Core) inserting same text 100.000 times in 10 threads.
This test reproduces described above situation (but with 3 minutes stall instead of 9 minutes) on my test platform.

using System;
using System.Threading;
using MySql.Data.MySqlClient;

namespace TestManticoreInsert
{
  class Program
  {
    private static string text =
      "sem viverra aliquet eget sit amet tellus cras adipiscing enim eu turpis egestas pretium aenean pharetra magna ac placerat vestibulum lectus mauris ultrices eros in cursus turpis massa tincidunt dui ut ornare lectus sit amet est placerat in egestas erat imperdiet sed euismod nisi porta lorem mollis aliquam ut porttitor leo a diam sollicitudin tempor id eu nisl nunc mi ipsum faucibus vitae aliquet nec ullamcorper sit amet risus nullam eget felis eget nunc lobortis mattis aliquam faucibus purus in massa tempor nec feugiat nisl pretium fusce id velit ut tortor pretium viverra suspendisse potenti nullam ac tortor vitae purus faucibus ornare suspendisse sed nisi lacus sed viverra tellus in hac habitasse platea dictumst vestibulum rhoncus est pellentesque elit ullamcorper dignissim cras tincidunt lobortis feugiat vivamus at augue eget arcu dictum varius duis at consectetur lorem donec massa sapien faucibus et molestie ac feugiat sed lectus vestibulum mattis ullamcorper velit sed ullamcorper morbi tincidunt ornare massa eget egestas purus viverra accumsan in nisl nisi scelerisque eu ultrices vitae auctor eu augue ut lectus arcu bibendum at varius vel pharetra vel turpis nunc eget lorem dolor sed viverra ipsum nunc aliquet bibendum enim facilisis gravida neque convallis a cras semper auctor neque vitae tempus quam pellentesque nec nam aliquam sem et tortor consequat id porta nibh venenatis cras sed felis eget velit aliquet sagittis id consectetur purus ut faucibus pulvinar elementum integer enim neque volutpat ac tincidunt vitae semper quis lectus nulla at volutpat diam ut venenatis tellus in metus vulputate eu scelerisque felis imperdiet proin fermentum leo vel orci porta non pulvinar neque laoreet suspendisse interdum consectetur libero id faucibus nisl tincidunt eget nullam non nisi est sit amet facilisis magna etiam tempor orci eu lobortis elementum nibh tellus molestie nunc non blandit massa enim nec dui nunc mattis enim ut tellus elementum sagittis vitae et leo duis ut diam quam nulla porttitor massa id neque aliquam vestibulum morbi blandit cursus risus at ultrices mi tempus imperdiet nulla malesuada pellentesque elit eget gravida cum sociis natoque penatibus et magnis dis parturient montes nascetur ridiculus mus mauris vitae ultricies leo integer malesuada nunc vel risus commodo viverra maecenas accumsan lacus vel facilisis volutpat est velit egestas dui id ornare arcu odio ut sem nulla pharetra diam sit amet nisl suscipit adipiscing bibendum est ultricies integer quis auctor elit sed vulputate mi sit amet mauris commodo quis imperdiet massa tincidunt nunc pulvinar sapien et ligula ullamcorper malesuada proin libero nunc consequat interdum varius sit amet mattis vulputate enim nulla aliquet porttitor lacus luctus accumsan tortor posuere ac ut consequat semper viverra nam libero justo laoreet sit amet cursus sit amet dictum sit amet justo donec enim diam vulputate ut pharetra sit amet aliquam id diam maecenas ultricies mi eget mauris pharetra et ultrices neque ornare aenean euismod elementum nisi quis eleifend quam adipiscing vitae proin sagittis nisl rhoncus mattis rhoncus urna neque viverra justo nec ultrices dui sapien eget mi proin sed libero enim sed faucibus turpis in eu mi bibendum neque egestas congue quisque egestas diam in arcu cursus euismod quis viverra nibh cras pulvinar mattis nunc sed blandit libero volutpat sed cras ornare arcu dui vivamus arcu felis bibendum ut tristique et egestas quis ipsum suspendisse ultrices gravida dictum fusce ut placerat orci nulla pellentesque dignissim enim sit amet venenatis urna cursus eget nunc scelerisque viverra mauris in aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod in pellentesque massa placerat duis ultricies lacus sed turpis tincidunt id aliquet risus feugiat in ante metus dictum at tempor commodo ullamcorper a lacus vestibulum sed arcu non odio euismod lacinia at quis risus sed vulputate odio ut enim blandit volutpat maecenas volutpat blandit aliquam etiam erat velit scelerisque in dictum non consectetur a erat nam at lectus urna duis convallis convallis tellus id interdum velit laoreet id donec ultrices tincidunt arcu non sodales neque sodales ut etiam sit amet nisl purus in mollis nunc sed id semper risus in hendrerit gravida rutrum quisque non tellus orci ac auctor augue mauris augue neque gravida in fermentum et sollicitudin ac orci phasellus egestas tellus rutrum tellus pellentesque eu tincidunt tortor aliquam nulla facilisi cras fermentum odio eu feugiat pretium nibh ipsum consequat nisl";
    static void Main(string[] args)
    {
      int threadCount = 10;
      Thread[] threads = new Thread[threadCount];
      for (int i = 0; i < threadCount; i++)
      {
        threads[i] = new Thread(TestInsert);
        threads[i].Start();
      }
      for (int i = 0; i < threadCount; i++)
        threads[i].Join();
    }
    static void TestInsert()
    {
      using (var connection =
        new MySqlConnection(
          "server=localhost;port=9306;pooling=true;connection reset=false;connection timeout=1000;default command timeout=1000;")
      )
      {
        connection.Open();
        for (int i = 0; i < 100000; i++)
        {
          try
          {
            using (var insertCommand = new MySqlCommand
              {CommandText = "insert into test_def (content) values(@content)"})
            {
              insertCommand.Connection = connection;
              var parameter = new MySqlParameter("content", MySqlDbType.Text);
              parameter.Value = text;
              insertCommand.Parameters.Add(parameter);
              insertCommand.ExecuteNonQuery();
            }
          }
          catch (Exception e)
          {
            Console.WriteLine(e);
            throw e;
          }
        }
      }
    }
  }
}

I think that may be matter of profiling.
Disk chunks have different structure, intended for achieve highest compression when storing indexes.
RAM chunk, in turn, intended for faster indexing (to provide real-timeness), and easier modifications. All is speed-oriented. When simple saving RAM-chunk it is just dumped as is, and it comsumes mostly io. When flushing - it is converted into disk format, occupying internal resources (mem, cpu) for it.
So, it would be good to profile (if you have possibility to apply sampling profiler) and look, what it is doing in the delayed stage, where everything is flushed.

how to build and run the program you posted?