-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
changelog reader ACCT_STAT insert hangs #90
Comments
Hi, how do you know exactly that the insert query on the ACCT_STAT table is hanging? Did you call e.g. If yes, what is the exact output of it, when it hangs? Eventually there are other SQL statements running at the same time? I can't imaging that just a call on the ACCT_STAT table is the cause of the issue. Hmm, probably there is an issue related to InnoDB since you wrote that with MyISAM there is no performance issue at this. Can you provide InnoDB specific settings e.g. with How long did the full scan take for how many entries? What is the size of the RAM on the database host? What kind of discs are you using for the database storage? Regards |
Hi, the output was from "show full processlist;", yes. There were no other active queries at the time. I find this strange myself. You can find my innodb settings below, but I also tried it with the MariaDB defaults, to no avail. Yes, with MyISAM it is working perfectly fine, it's just InnoDB. Full scan took around 3.76 hours for 21551937 entries.
|
Hi, one important note for you I missed in my first post...
If you have performance issues in general with InnoDB it is not getting better, since it has higher hardware requirements and is slower IMHO then MyISAM. What do you exactly mean with 'we are having performance issues anyway'? Can you figure out if the database server has swapped or the RAM is sufficient when running with InnoDB? About the full scan you have mentioned... Did you do that with accounting information enabled e.g. is the ACCT_STAT table populated with data after the full scan took place? What is the state of the query when you call Since we are using InnoDB in Version 5.5.52 I am not quite familiar with all the parameters you have provided. But as far as I can see, there is not much suspicious looking to me. Anyway I would recommend you to use mostly the default values for the parameters to have a good starting point e.g. setting Not sure, we need more investigation about this here, but the Do you know exactly the disc spaces required for the innodb tables? You should also check if the Buffer Pool has no free pages left: Even better would be to try to understand how your Inno DB Buffer Pool is performing... Here are few interesting and helpful resources to get started...
After checking the current state I would do a clean full scan of you Lustre filesystem installation with an empty Buffer Pool. My naive assumption would be, that maybe your Buffer Pool is full and gets struggling when even more data is inserted and rows are updated by the processing of Lustre changelogs? You could also check the logs from Robinhood during full scan and changelog processing regarding speed and 'EntryProcessor Pipeline Stats' which is documented on the Robinhood documentation... probably you can figure out that the database performance is the bottleneck. Hope that helps! Gabriele one important note for you I missed in my first post...
If you have performance issues in general with InnoDB it is not getting better, since it has higher hardware requirements and is slower IMHO then MyISAM. What do you exactly mean with 'we are having performance issues anyway'? Can you figure out if the database server has swapped or the RAM is sufficient when running with InnoDB? About the full scan you have mentioned... Did you do that with accounting information enabled e.g. is the ACCT_STAT table populated with data after the full scan took place? What is the state of the query when you call Since we are using InnoDB in Version 5.5.52 I am not quite familiar with all the parameters you have provided. But as far as I can see, there is not much suspicious looking to me. Anyway I would recommend you to use mostly the default values for the parameters to have a good starting point e.g. setting Not sure, we need more investigation about this here, but the Do you know exactly the disc spaces required for the innodb tables? You should also check if the Buffer Pool has no free pages left: Even better would be to try to understand how your Inno DB Buffer Pool is performing... Here are few interesting and helpful resources to get started...
After checking the current state I would do a clean full scan of you Lustre filesystem installation with an empty Buffer Pool. My naive assumption would be, that maybe your Buffer Pool is full and gets struggling when even more data is inserted and rows are updated by the processing of Lustre changelogs? You could also check the logs from Robinhood during full scan and changelog processing regarding speed and 'EntryProcessor Pipeline Stats' which is documented in https://github.com/cea-hpc/robinhood/wiki/pipeline_tuning - probably you can figure out that the database performance is the bottleneck. Hope that helps! Gabriele |
Hi, I'm using robinhood 3.1.0 (but this also happened with older versions) and have the problem that with engine = InnoDB the changelog reader always hangs on and INSERT into ACCT_STAT. This is the query:
INSERT INTO ACCT_STAT(uid,gid,type,size,blocks, count,sz0,sz1,sz32,sz1K,sz32K,sz1M,sz32M,sz1G,sz32G,sz1T) VALUES (NEW.uid,NEW.gid,NEW.type,NEW.size,NEW.blocks,1,NEW.size=0, NAME_CONST('val',3)=0, NAME_CONST('val',3)=1, NAME_CONST('val',3)=2, NAME_CONST('val',3)=3, NAME_CONST('val',3)=4, NAME_CONST('val',3)=5, NAME_CONST('val',3)=6, NAME_CONST('val',3)=7, NAME_CONST('val',3)>=8) ON DUPLICATE KEY UPDATE size=CAST(size as SIGNED)+CAST(NEW.size as SIGNED),blocks=CAST(blocks as SIGNED)+CAST(NEW.blocks as SIGNED), count=count+1,sz0=sz0+(NEW.size=0), sz1=sz1+( NAME_CONST('val',3)=0), sz32=sz32+( NAME_CONST('val',3)=1), sz1K=sz1K+( NAME_CONST('val',3)=2), sz32K=sz32K+( NAME_CONST('val',3)=3), sz1M=sz1M+( NAME_CONST('val',3)=4), sz32M=sz32M+( NAME_CONST('val',3)=5), sz1G=sz1G+( NAME_CONST('val',3)=6), sz32G=sz32G+( NAME_CONST('val',3)=7), sz1T=sz1T+( NAME_CONST('val',3)>=8)
It just does not terminate, even if there is no load at all on the database. We are using mariadb 10.1.30.
The funny thing is, that it works perfectly fine when I just do a full scan (--scan --once), but it only happens in the changelog reader (--read-log).
Also, this only happens with engine = InnoDB. If I fall back on MyISAM, it works fine as well. But since InnoDB is the recommendation and we are having performance issues anyway, I wanted to try InnoDB.
Any idea what may be causing this? It's not really a new issue, I remember having tried this already a year ago with older MySQL and robinhood versions, same problem.
Let me know if you need any more information.
The text was updated successfully, but these errors were encountered: