Performance issues

Alan DeKok aland at deployingradius.com
Fri Sep 30 13:12:32 UTC 2022


On Sep 30, 2022, at 4:08 AM, Imdad Hasan <imdadalikadiwala0 at gmail.com> wrote:
> Actually the problem is something different. i checked all queries and all
> indexes. even i enabled MySQL logs for slow queries + without indexed
> queries. and it's showing none..

  When the log says "sql module is blocked", it's because the SQL module is blocked.  And that's because the SQL server took over 5 seconds to respond to FreeRADIUS.

  It doesn't matter what else is going on.  That's what's happening.

> Another main thing is MySQL is only taking 5-10% cpu max. i already
> increased the max_connection as well with 1024 from the first day of
> installation.
> 
> So, I am monitoring how many connections are opened by WebUI and FreeRADIUS
> servers separately.

  None of that matters.

  Maybe once a day you hit the SQL server with tons of admin queries, and then it takes 5 seconds to respond to FreeRADIUS.  Or once a day it runs an automatic table vacuum, and blocks the server.

> So, everytime WebUI (NGINX + PHP-FPM) has so many connections like around
> 150. But on the other hand the FreeRADIUS has only 15 to 20 max
> connections. why it's not taking full advantage of MySQL
> resources/connections.
> 
> I also increased max_server from 32 to 64 in radiusd.conf but still it's
> not creating more connections.

  The connections to SQL are managed in mods-enabled/sql.  Please read that, and edit that.

> And whenever i restart freeradius it shows *rlm_exec unblocked* (i think
> because of intruption in running php processes.). But the *rlm_sql
> unblocked* is sometimes in a day without any reason..

  Ask the SQL server why it randomly doesn't respond to FreeRADIUS for 5+ seconds.

> But I am sure that
> *rlm_sql* means pre-compiled queries Or action update queries. Right?

  I mean any SQL queries.  Nothing else in the server implements SQL.  Only rlm_sql.

> Please correct me if I am wrong..
> 
> The *rlm_sql unblocked (with conflict packet)* problem is from the
> configuration of freeradius.

  No.

> it's not from a php exec script.

  I never said it was.

> Please suggest to me what will be the bottleneck in this issue.

  I did.

  Fix SQL.  No amount of poking FreeRADIUS will fix this.  This isn't a FreeRADIUS issue.  I really don't know how else to say that.

  If you're not going to believe me, I don't see why you're asking questions on this list.

  Alan DeKok.



More information about the Freeradius-Users mailing list