Hello Lukas,
the x_cons output show Dev_IO gives information about the asynchronous IO statistics.
MaxDB is oding asynchronous IO means that the User Task which is executing the SQL command does not do the IO by itself but forward the IO request to the Dev_THreads . They are responsible for the IO forwarding to the IO subsystem.
You have several IO Threads or IO worker Threads per Data Volume therefore you have several entries for the same Data volume. The statistics shows how many worker threads were active since the last reset of the console or restart of the database.And you get information about the average read /write time per read and write via the Dev-threads. So it does not look so bad on your system.
The Task Details give us more detailed information about what ressources the Task is consuming.
In Your example Task T128 has Application PID 1240, has executed 32 SQL commands since reset of the console. You'll get the dispatch count of the internal tasking and you'll see the reads were done on DISKD0041 more than 830.000 read IO were executed and per read IO 1 Page was read. And you get the time for read Io - the relative and abs dev read time are fine - we do not have a gap here, emans additional wait time.
The command monitor only loggs SQL commands which are related to the thresholds when you started the Command monitor. If the statement does not fulfill the threadsholds it is not logged.
The you must use the SAP transaction ST05 SQL Trace to log the Commands. Here you can execute the EXPLAIN plan of the long running statement. May be you have to optimize this statement with additional indexes.
So you'll see this is a very complex analysis which cannot be done in detail via SDN. If you are a SAP customer I recommend to open an incident and request performance analysis of your statement.
Regards, Christiane