Sentinel db table question

New Member Joined: Aug 05, 2005 Posts: 19

A friend of mine who's site I help out with recently moved his site to a dedicated server, several times recently the server has crashed and when enquiring with their customer support he recieved this.

Quote:

Thank you for contacting us.

Recently we had a chance to look at some of the processes that are
causing problems and it appears that it is mostly MySQL that is causing
problems. We looked further into MySQL and can see a couple of things
that could be changed to provide better performance.

Table _nsnst_tracked_ips of DB is locked for all
other modfying operations. This is because the table is MyISAM. Changing
the table to InnoDB would play better with MySQL because it would allow
row-based locking, instead of a complete table being locked. Will
definitely save on memory.

Does this make sense to anybody?

Would changing the table type solve this problem?

Should he do it?

TIA. Smile

registered · Posted: Sun May 20, 2007 5:30 pm

I believe that PHP-Nuke has always been MyISAM. Not sure about switching to InnoDB. Not sure what is involved with that, nor the impacts, and unfortunately I do not have time to research it (others may know).

However, do make sure that you run the "Optimize" from within PHP-Nuke's administration control panel or phpMyAdmin often, especially if you have an active site.

Posted: Sun May 20, 2007 5:36 pm

That's why I'm confused, I'm assuming they just mean change the 1 table to InnoDB but being unsure I thought I'd ask first.

And yes, I do optimize regularly, it's a very active site.

Posted: Wed May 23, 2007 5:31 pm

So can anyone give me a yes/no on whether changing this table will have any effect??

registered · Posted: Wed May 23, 2007 9:12 pm

Well you could change it to InnoDB, but it will only work if your underlying system supports it. As I understand it, this just changes out the storage engine, so in theory the application (Sentinel) won't know the difference. However I have read things in the MySQL documentation that say certain things work differently depending on the storage engine.

I really don't think that message your host sent you is worth a lot.

Posted: Fri May 25, 2007 6:54 am

darryl, I agree with Gremmie. Raven's site here is one of the most active that I have seen and he does not have these issues. I believe that your host has not done a thorough enough analysis. Unfortunately, this type of analysis takes experience in many different areas and if they are not willing to throw bodies at it....

In the almost 3 years now that I have been at this, I have NEVER once heard anyone come up with anything remotely close to this.

Sorry. I know that does not help you much. I would ask them to monitor your server (they should have automated tools for this!) and at the next crash, engage them immediately to review what was going on in the system at that time.

registered · Posted: Fri May 25, 2007 7:26 am

How much usage do you get on this dedicated server? I've never had such issues on mine. It really sounds like a configuration issue, though theoretically their suggestion could be valid

Posted: Fri May 25, 2007 2:58 pm

Like I said it's not my site so I didn't want to fiddle with something without clarification as what the host said made no sense to me.

Anyway, I've changed the setting in sentinel config for stored ip's from 7 days down to 3 because the table was reaching over 60mb's set at 7 days.

I'll leave it alone and see if he has any more problems.

Posted: Fri May 25, 2007 9:16 pm

It's very.. technical. I'm not a MySQL expert, it could be that the host is right, esp given the size of that particular table. Mine is only 26 MB, I've never had that problem... but I am on a nice dedicated server too Smile

Good to ask Bob Marion, see if that's an optimization that would help