View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002943 | unreal | ircd | public | 2006-06-03 07:25 | 2013-05-07 01:48 |
Reporter | Assigned To | ||||
Priority | normal | Severity | minor | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
OS | Fedora Core | OS Version | 4 (sec. patch?) | ||
Product Version | 3.2.5 | ||||
Target Version | 3.3-alpha0 | Fixed in Version | 3.4-alpha1 | ||
Summary | 0002943: ircd logging: use fflush instead of fopen+fclose all the time | ||||
Description | I noticed we open/close the ircd log each time. how about we simply flush instead and keep the fd open? Should be better for performance? | ||||
Additional Information | ** NOTE: The below is about the discussion of a 99% CPU increase issue, but this was actually about regex, this issue is kept for the fopen+fclose --> fflush thing ** | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
Logging never showed any (significant) cpu impact in my speedresults. So if there was any cpu increase or spike or even 99% cpu usage that must be some kind of bug. I too, have wondered why we do the close+open thing all the time instead of fflush(), maybe the author was lazy. Though the (only?) good thing about it is that you don't have to worry if someone rm's the file ;) |
|
If I recall, it was because of Windows. I seem to remember there having been an issue where if we didn't fclose(), and I tried to open the file in notepad, it would give one of those fun "file is in use" errors but I think that was only a Win 9x issue so it could easily be changed now. |
|
New material which has gotten us to realize what the problem is // block repeting letters spamfilter { regex "^.*(\w)\1{15,}.*$"; target channel; action block; reason "Chars flood"; }; This, with a normal user flooding and moderate server traffic, causes the ircd to go high up in CPU (15%, where normal traffic is 1-2%. A ltrace is at http://bsd.tspre.org/~stskeeps/ltrace.out.gz ). With a good amount of users doing the same, it'd reach 99% |
|
Backreferences are an NP-complete problem. That kinda makes it inefficient by definition, doesn't it? |
|
codemastr: ack :P stskeeps: yeah regexes can be a pain, especially with backrefs.. the TRE author even said to me "if you care about speed, don't use backreferences" ;P EDIT: *grin* timing ;p |
|
Well, true, but it would be a hell lot more efficient if it didn't go out and do a strncmp to compare one character.. and just did a char comparision instead :> |
|
So..... now this bugreport is screwed up.. what to do about it... Since we cannot do anything about regex, and the TRE author probably can't either, I suppose I'll keep it as-is for the fflush-logging tactic, and rename it to that ;p |
|
[quote]Well, true, but it would be a hell lot more efficient if it didn't go out and do a strncmp to compare one character.. and just did a char comparision instead :>[/quote] Well, you know C, stop being lazy and go make a patch :P |
|
Let's move this regex talk to 0002887, even though that is about ++ :P |
|
Fixed in .2446 |
|
http://hg.unrealircd.org/hg/unreal/rev/b0d1474ecb50 |
Date Modified | Username | Field | Change |
---|---|---|---|
2006-06-03 07:25 |
|
New Issue | |
2006-06-03 07:29 | syzop | Note Added: 0011828 | |
2006-06-03 07:41 | syzop | Relationship added | child of 0002936 |
2006-06-04 13:15 |
|
Note Added: 0011840 | |
2006-06-04 16:07 |
|
Note Added: 0011844 | |
2006-06-04 16:41 |
|
Note Added: 0011845 | |
2006-06-04 16:42 | syzop | Note Added: 0011846 | |
2006-06-04 16:45 | syzop | Note Edited: 0011846 | |
2006-06-05 04:32 |
|
Note Added: 0011855 | |
2006-06-05 04:33 |
|
Note Edited: 0011855 | |
2006-06-05 16:36 | syzop | Note Added: 0011863 | |
2006-06-05 16:38 | syzop | Summary | Problem with 99% cpu with connection logging enabled => ircd logging: use fflush instead of fopen+fclose all the time |
2006-06-05 16:38 | syzop | Description Updated | |
2006-06-05 16:38 | syzop | Additional Information Updated | |
2006-06-05 21:54 |
|
Note Added: 0011869 | |
2006-06-06 10:17 | syzop | Note Added: 0011879 | |
2006-11-03 17:40 | syzop | Relationship deleted | child of 0002936 |
2007-04-27 03:25 |
|
Status | new => acknowledged |
2007-05-19 14:38 | Trocotronic | Status | acknowledged => assigned |
2007-05-19 14:38 | Trocotronic | Assigned To | => Trocotronic |
2007-06-11 12:50 |
|
Assigned To | Trocotronic => |
2007-06-11 12:50 |
|
Status | assigned => acknowledged |
2007-06-21 15:43 |
|
Status | acknowledged => resolved |
2007-06-21 15:43 |
|
Fixed in Version | => 3.3-alpha0 |
2007-06-21 15:43 |
|
Resolution | open => fixed |
2007-06-21 15:43 |
|
Assigned To | => stskeeps |
2007-06-21 15:43 |
|
Note Added: 0014398 | |
2011-07-19 13:48 | syzop | Assigned To | stskeeps => |
2011-07-19 13:48 | syzop | Status | resolved => needs re porting |
2011-07-19 17:11 | syzop | Target Version | => 3.3-alpha0 |
2013-05-07 01:47 |
|
Note Added: 0017510 | |
2013-05-07 01:47 |
|
Status | needs re porting => resolved |
2013-05-07 01:47 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
2013-05-07 01:47 |
|
Assigned To | => nenolod |