Heavy disc load

kermithermos · #11 (**permalink**) June 8th, 2023

Yes you are right, there are other threads in older logs when more than one downloads were active. The log from above was when only one download was activated. I stopped all other downloads bec of better overview in logs.

But why is it called so often? Is one call not enough? Its only called in the shutdown(), flushing here makes sense and in the BufferVolumeTracker I dont know what that is for.

Ah theres this code in the inner class Sync extended from AbstractQueuedSynchronizer

Code:

        @Override
        protected final int tryAcquireShared( int acquires ) 
        {
            for (;;) 
            {
                int available = getState();
                int remaining = available - acquires;
                if ( remaining < 0 )
                {
                    dataWriter.triggerWriteCycle();
                    return remaining;
                }
                if ( compareAndSetState(available, remaining) )
                {
                    return remaining;
                }
            }

Seems the flushing of the buffer is never done in one step (or cannot be shure it is flushed 100%) and therefore this repeating calls until remaining is 0 to be shure all is flushed.

That explains a least these massive log entries and maybe the strange disc access noise while writing (short access patterns). Increasing Buffer sized helped a little bit but is never smooth enough.

The reason for this "fragmented writing noise" is probably this scopes play a role here, when the file parts are fragmented downloaded, the file size is increased from time to time to the highest fragments position. File is not created as a whole in the first place so you have real and bad fragmentation on disc.

Kay677 · #12 (**permalink**) November 7th, 2023

Hello, everyone. It was useful to read. Now I understand why the buffer is cleared so often.