MySQL performance

[Lorenzo Milesi]

> For one, it can show you which part is slow (is it really the db, or
> is it something else). Another one is it can show relevant parts of
> the config which can help others pinpoint the problem. Pasting only
> PART of the debug log will only get you (at best) partial guesses.

Ok, I missed this, I thought was a suggestion to me :-)
http://paste.ubuntu.com/693812/
this is the startup log, with the first authentication requests. as you can see from the same nas (.67) the first request is with the wrong pw, while the second is fine and Access-Accept is sent back.
I obfuscated pw and ips, let me know if there is anything useful you can see.

Another weird thing I noticed is that as you can see at line 155 in the middle of an Access-Accept report there's another rad_recv, like it's mixing up output.
I don't know if this is a problem, or if it was doing it already, but still looks strange.


Now I'm running -XX, I will post later something from that.

> Maybe. The debug log will also say something like "warning, unreadable
> password, check shared secret" (or something like that). Did you find
> it? Did you simply ignore it, or do what it suggested?

I grepped for "warn" and "err" and found nothing in the debug log. Just a warning for a proxied request, but nothing else.

> Some things to check:
> - did the different case (readable vs unreadable password) comes from
> the same NAS? 

Yes.
Let's say most of the problems come from a newly deployed nas.

> - is the shared secret correct?

Yes. This puzzles me, some (half?) of the auth end successfully, others won't, and I cannot figure out where it is failing.
Indeed I get the "check secret" message you suggested, but as said some users go through, some others don't... :/

> - does the login issue happens for ALL users or only for SOME servers?

As said above most of the problems come from a single nas, which is the busiest. Occasionally other nases raise the issue, but much less often. 

> Basically if it's specific user/NAS problem, then you need to focus on
> those particular users. Again, debug log will usually help you find

I raised even more the number of SQL threads and seems I see less radius errors on the client.


Now I try to compare the failed reqs with the log, will report back.
Thank you very much!
cheers
-- 
Lorenzo Milesi - lorenzo.milesi at yetopen.it

YetOpen S.r.l. - http://www.yetopen.it/
Via Carlo Torri Tarelli 19 - 23900 Lecco - ITALY -
Tel 0341 220 205 - Fax 178 6070 222

GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it

-------- D.Lgs. 196/2003 --------

Si avverte che tutte le informazioni contenute in questo messaggio sono
riservate ed a uso esclusivo del destinatario. Nel caso in cui questo
messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo
senza copiarlo, a non inoltrarlo a terzi e ad avvertirci non appena
possibile.
Grazie.