Regeneration speed with mysql 5 Database

  • Hi


    After changing to 1414 and making some changes in the dicom.sql i lost my database and had to regenerate. Regeneration worked fine with a speed of appr. 15 to 20 images /second. Stopping on memory errors was fixed by the dicom.ini tag -holdonerrors-. The database consists of appr. 15.000 studies on about 400Gb. As I understood the manual, mysql should have no speed problems with that. I changed the mysql.ini to the manuals recommendation. But after approx. 10.000 studies the system slowed down dramatically to less than one image per second.
    System memory, network etc. looks fine (the data is on a network storage tower).
    Any suggestions, how i can check the problem. I am definitly no mysql expert, but i installed it close to the manual instruction.
    (is it possible, because i activated bigendianexplizit in the dgateop.lst for test reasons (worklist communication with siemens flurospot, which seems to use bigendian )?


    Thanks


    Uli

  • I had a similar problem running with a Lacie brand NAS drive (Ethernet 1TB drive).
    I finally pinned it on the Lacie NAS unit. I did not encounter the same problem using a local drive or a different (thecus n5200 Raid) NAS.
    Consider trying with a non network source.
    Hope this helps, I was pulling my hair out for a while.
    LJJ

  • Hi


    thanks for your reply.
    Yes we are also using an thecus n5200 Raid, working fine until now with no measurble speed diffences regarding normal study transfer compared to a local disk.


    Uli

  • Hi,


    I guess the problem could be related to the place that the mysql server files are stored. Are these on the local drive?


    Mysql speed problems in the past were due to failure to create the indices. You might double check using a mysql management utility that all the conquest DICOM tables have indices.


    Marel

  • All the mysql server files are stored local.
    The inidices are present for the tables.


    I guess its not really a mysql-problem. Checking with an administration tool, mysql doesnt really seem to be busy during the regeneration. Maybe its a windows problem to handle big directories, when the files are on a NFS.
    E.g. when I open the directory with windows explorer, it takes about 30 sec. to show the directory.
    I found a workaround for my problem. When the regeneration slows down, I move the rest of the files to another directory. When the regeneration found the last file and finishs the regeneration process, I drop the rest of the files into conquest, having a sufficient regeneration speed again. This is definitly not a sophisticated way to do it, but it s still faster than less than 1 image per second. I hope I never have to regenerate the db again.
    By the way, is there a way to regenerate the database only using mysql commands, or does conquest have to initiate the process ?


    Uli

  • The data used to populate the database tables comes from the dicom header in each file and must be extracted, formatted and inserted into the database by a dicom processing program, in this case conquest.


    Mysql and other database programs only know how to process SQL (database language) commands.

  • Hi,


    I had a similar problem with mysql 5.0 version greater than 5.0.22. When I reverted to 5.0.22 and used the my.ini configuration recommended in the conquest manual 14.12c, that solved the performance problem.


    What version of mysql do you currently use?


    I hope this helps

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!