[TYPO3-english] Hunging select from fe_sessions and fe_users

[Vahan Amirbekyan]

Ries, thanks much for your response, it gave me a few ideas that I am 
trying out now ( drop and recreate indexes is one of them ..)
Tell me one thing please as I do not have time now to investigate it.
Why do we see this queries on connections that do not have users logged in?
I got yahoo crawling now my site and tons of these queries just crush 
the server.
Why typo3 queries fe_users at all for connection without users on the 
client side?
or i am reading the situation wrong?


ries van Twisk wrote:
> 
> On Mar 25, 2009, at 8:14 PM, Vahan Amirbekyan wrote:
> 
>> guys,
>> I am seeing tons of queries like this one in the show process:
>>
>> SELECT * FROM fe_sessions,fe_users WHERE
>> fe_sessions.ses_id = 'e361c16a9f' AND fe_sessions.ses_name = 
>> 'fe_typo_user'
>> AND fe_sessions.ses_userid = fe_users.uid
>> AND (fe_sessions.ses_iplock='38.99'OR 
>> fe_sessions.ses_iplock='[DISABLED]')
>> AND fe_sessions.ses_hashlock=268278894 AND fe_users.disable=0 AND
>> fe_users.deleted=0 AND (fe_users.starttime<=1238029426) AND
>> (fe_users.endtime=0 OR fe_users.endtime>1238029426)
>>
>>
>> I added indexes on fe_sessions.ses_userid and fe_sessions.ses_hashlock
>> but it did not help much.
>>
>> First, why suddenly I am seeing this selects?
>> What code are they from?
>> And should I use MyISAM or InnoDB for these fe_sessions and fe_users 
>> tables?
>> I am using InnoDB.
>> _______________________________________________
> 
> 
> 
> I don't have a direct answer, but be reminded that MySQL doesn't support 
> bitmap indexes.
> Adding a couple of indexes fill not gain you much, and MySQL 'might' 
> even select the incorrect index
> under some conditions.
> 
> Check if you have an index on fe_sessions.ses_id, this fields seems to 
> be the one with the highest cardinality,
> check that to be sure, I do this from the top of my head.
> 
> You might want to try to set fe_sessions to a innoDB type, I am not sure 
> if a lot of deletes happen on that table,
> MyISAM has a horrible track record when you need high concurency (lot's 
> of read/write on the same table).
> 
> Current advice is to remove the indexes and re-investigate, check if you 
> have an index on fe_sessions.ses_id.
> 
> Dmitry knows more about this stuff.. I am not really a MySQL guy.
> 
> Ries
> 
> 
> 
> 
>