2016-11-30 - Re: [GRASE-Hotspot] question on GRASE freeradius temp file

Header Data

From: Gianluca Filippini <gi***4@gmail.com>
Message Hash: a2bca50c6eb7fcc6ad56ecaa43a73f1f0cd678f7e8c7235aba8e28fe4720d930
Message ID: <35bf2ec4-de37-4744-a789-59d5f89f9d17@grasehotspot.org>
Reply To: <7136dca7-d9a9-9ed5-0ad4-91e2a568fd1a@radez.hr>
UTC Datetime: 2016-11-30 03:40:47 UTC
Raw Date: Wed, 30 Nov 2016 02:40:47 -0800

Raw message 

yes. disk is only 20% full on the main partition and a lot less on the 
system partition.

I tried again removing the "unix" entry in the config file. I restarted 
freeradius manually and now the radwtmp file does not increase anymore.

but I still have this delay (10/20s) every time I request a web link.

after I get the page everyting is smooth again, but if I type another link 
... another 10/20s of delay.

it is something like the dns is taking too much time, but I have listed the 
8.8.8.8 and 8.8.4.4 dns

mmm ... puzzled


On Wednesday, November 30, 2016 at 9:50:48 AM UTC+1, drazen.zuvela wrote:
>
> Hi Gianluca
> Just to be sure disk space is OK try "df" at console. Look for any 
> partition which may be full or near full. 
>
> Rgds. 
> Drazen
>  
> 29.11.2016. u 23:52, Gianluca Filippini je napisao/la:
>
> thanks a lot for your quick reply Tim!
>
> mmm .. weird .. If I just remove that line in the default.grase config and 
> reboot the machine freeradius does NOT come up anymore.
> I put back that line .. and it works again... really strange
> (I know .. I can just restart the service, just want to make sure 
> everything works on a cold start)
>
> regarding the user load: this "delay" issue has been a complain from a 
> long time, but I cannot pinpoint if there was a jump.
>
> definitely I saw the problem myself ... user is stuck waiting for minutes 
> .. and then suddenly the page arrives really fast!
>
> the internet speed is tested to be 80/90Mbit/s ... the only bottleneck is 
> the grase linux box,
> so either something related to freeradius checking for concurrent sessions 
> or squid3 having troubles,
> but afaik we have cache disabled by default in squid3 .. so that should 
> not delay the query/response.
>
> the fact is that today I did a reboot when the issue was there ... and 
> suddenly surfing was fast again,
> so ... something related to some "incremental/overtime" issue 
>
> at the time of the problem cpu load was 2%, memory was 20%, no swap
> :-(
>
>
>
>
>
> On Tuesday, November 29, 2016 at 9:53:52 PM UTC+1, timwhite88 wrote: 
>>
>> Hi Gianluca
>>
>> We use the raddact table to detect multiple logins. Looking at 
>> https://github.com/GraseHotspot/grase-conf-freeradius/blob/master/freeradius/sites-available/default.grase#L464 
>> we can comment out that line which should prevent the radwtmp file being 
>> written at all. You'll find that file in /etc/freeradius/sites-available/
>> I'll aim to fix that in the package shortly.
>>
>> Let us know if that fixes your issue. If it's recently become an issue, 
>> I'd be looking at the volume of users you are getting, and see if that has 
>> increased recently.
>>
>> Regards
>>
>> Tim
>>
>> On Wed, Nov 30, 2016 at 5:24 AM, Gianluca Filippini <
>> gi***.@gmail.com> wrote:
>>
>>> Hi Tim,
>>> in a previous post I was referring to poor performance on a old 
>>> installation of grase (3.7)
>>>
>>> the issue is presenting as a long delay from the moment a registered 
>>> user asks for a website and the moment he gets the page.
>>> the delay is huge ... up to minutes ... on a very powerful machine (4 
>>> cores 3Ghz Xeon with 16G ram) and a very fast internet link (100Mbit/s 
>>> fiber)
>>> the average internet load is 90 users connected with a 20/30Mbit/s 
>>> traffic.
>>>
>>> so I focused my attention on the freeradius package and I found that the 
>>> var/log/freeradius/radwtmp was getting huge after few days ... up to 600M+
>>>
>>> my understanding is that this file is used by freeradius to detect 
>>> MULTIPLE SESSION which indeed I do *not* allow in my GRASE user account 
>>> group.
>>>
>>> ===
>>> My theory is that every time a user does a request this file has to be 
>>> parsed to prevent double sessions, adding a big delay to the user response,
>>> so I deleted the file (it is a temp file) and I will monitor performance 
>>> next .. but ..
>>>
>>> is this some sort of known issue that has been addressed in v.3.8 ?
>>>
>>> I see that multiple session can be adressed either by using mysql 
>>> (raddact table) OR radwtmp file .. 
>>> do you know which one we are using?
>>>
>>> thanks
>>> -- 
>>> This mailing list is for the Grase Hotspot Project 
>>> http://grasehotspot.org
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Grase Hotspot" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to gr***.@grasehotspot.org.
>>> To post to this group, send email to gr***.@grasehotspot.org.
>>> Visit this group at 
>>> https://groups.google.com/a/grasehotspot.org/group/grase-hotspot/.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/3153bc50-6244-4d92-a9a9-0e00725444e2%40grasehotspot.org 
>>> <https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/3153bc50-6244-4d92-a9a9-0e00725444e2%40grasehotspot.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> -- 
> This mailing list is for the Grase Hotspot Project http://grasehotspot.org
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Grase Hotspot" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to gr***.@grasehotspot.org <javascript:>.
> To post to this group, send email to gr***.@grasehotspot.org 
> <javascript:>.
> Visit this group at 
> https://groups.google.com/a/grasehotspot.org/group/grase-hotspot/.
> To view this discussion on the web visit 
> https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/cbf014e4-5794-4616-81a0-80e46dead5bd%40grasehotspot.org 
> <https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/cbf014e4-5794-4616-81a0-80e46dead5bd%40grasehotspot.org?utm_medium=email&utm_source=footer>
> .
>
>
>

Thread