Re: don't wait rlm_sql response

[Fajar A. Nugraha]

On Tue, Apr 2, 2013 at 9:13 AM, Mitsuhiro Nakamura nakam...@1pacific.ddo.jp
 wrote:


 Alan,

 Thank you.
 Our database has some problem and the response is slow.
 Since the problem itself seems to take long time to fix it, we wanted to
 avoid it.



Are you using sql ONLY for accounting?

If yes, then Olivier's suggestion on using decoupled accounting might help.
In fact, on some scenarios where the db is actually fast but has a somewhat
high latency (e.g. mysql cluster), I'd highly recommend that.

However, since you say the db response is slow, you'd only be putting
band-aid on the wound. The detail file reader may very likely end up hours
or days behind the actual accounting packet.

If there is no way to do, then we will try to find the otherway.


Fix the db. It's the right thing to do.

The usual causes are:
- too much data (e.g. tens of millions of rows from years of accounting
data in a single table)
- inefficient indices (too many index which slows down writes, or no index
used which slows down reads)
- not enough disk IOPS available (e.g. using 2 x HDD in mirror mode for a
db with hundreds of writes requirement per second)
- default, untuned db

A qualified dba should be able to help you.

-- 
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: don't wait rlm_sql response

[Mitsuhiro Nakamura]

Yes we use sql only for accounting. We will try decoupled accounting then.

There are some complex problems on our DB, the team and DBA are working
on it too.Thank you for the advice.


Thank you all for your help :)

Nakamura


 On Tue, Apr 2, 2013 at 9:13 AM, Mitsuhiro Nakamura [hidden email] wrote:

 Alan,

 Thank you.
 Our database has some problem and the response is slow.
 Since the problem itself seems to take long time to fix it, we wanted to
 avoid it.



 Are you using sql ONLY for accounting?

 If yes, then Olivier's suggestion on using decoupled accounting might
help. In fact, on some scenarios where the db is actually fast but has a
somewhat high latency (e.g. mysql cluster), I'd highly recommend that.

 However, since you say the db response is slow, you'd only be putting
band-aid on the wound. The detail file reader may very likely end up
hours or days behind the actual accounting packet.

 If there is no way to do, then we will try to find the otherway.


 Fix the db. It's the right thing to do.

 The usual causes are:
 - too much data (e.g. tens of millions of rows from years of
accounting data in a single table)
 - inefficient indices (too many index which slows down writes, or no
index used which slows down reads)
 - not enough disk IOPS available (e.g. using 2 x HDD in mirror mode
for a db with hundreds of writes requirement per second)
 - default, untuned db

 A qualified dba should be able to help you.

 --
 Fajar

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

don't wait rlm_sql response

[Mitsuhiro Nakamura]

Hi all,

When using rlm_sql, it always wait for response from database.
Is there any way to configure to avoid it?
(We don't wanna wait for its result after prosessing)

accounting {
detail
sql -wish to prosess it here without waiting for result
}


We'd appreciate if anyone can answer this promptly.
Thank you,



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: don't wait rlm_sql response

[Alan DeKok]

Mitsuhiro Nakamura wrote:
 When using rlm_sql, it always wait for response from database.

  That's how it works.

 Is there any way to configure to avoid it?
 (We don't wanna wait for its result after prosessing)

  Why?

 accounting {
 detail
 sql -wish to prosess it here without waiting for result
 }
 
 
 We'd appreciate if anyone can answer this promptly.

  That's nice, but no one is getting paid to help you.  Asking for
prompt responses is not helpful.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: don't wait rlm_sql response

[Mitsuhiro Nakamura]

Alan,

Thank you.
Our database has some problem and the response is slow.
Since the problem itself seems to take long time to fix it, we wanted to
avoid it.

If there is no way to do, then we will try to find the otherway.


Regards,

Nakamura



 Mitsuhiro Nakamura wrote:
  When using rlm_sql, it always wait for response from database.

   That's how it works.

  Is there any way to configure to avoid it?
  (We don't wanna wait for its result after prosessing)

   Why?

  accounting {
  detail
  sql -wish to prosess it here without waiting for result
  }
 
 
  We'd appreciate if anyone can answer this promptly.

   That's nice, but no one is getting paid to help you.  Asking for
 prompt responses is not helpful.

   Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: don't wait rlm_sql response

[Olivier Beytrison]

On 2 avr. 2013, at 04:13, Mitsuhiro Nakamura nakam...@1pacific.ddo.jp wrote:

 
 Alan,
 
 Thank you.
 Our database has some problem and the response is slow.
 Since the problem itself seems to take long time to fix it, we wanted to
 avoid it.

Look at the decoupled accounting virtual server example. 

Olivier
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html