• memory leaks

    From Matt Bedynek@1:19/10 to All on Thu Sep 22 01:30:26 2016
    In the past I have observed some memory leaks in jamnntpd. I run the
    smapi version where as others run the original base but I am curious
    how stable has your release been? Do you sometimes have to restart
    it? How long does it run before it dies. If it runs for a few weeks
    how much memory does it consume?

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Paul Quinn@3:640/1384 to Matt Bedynek on Thu Sep 22 17:40:33 2016
    Hi! Matt,

    On 22 Sep 16 01:30, you wrote to All:

    In the past I have observed some memory leaks in jamnntpd. I run the smapi version where as others run the original base but I am curious
    how stable has your release been? Do you sometimes have to restart
    it? How long does it run before it dies. If it runs for a few weeks
    how much memory does it consume?

    I have three systems going 24/7. There's a Win32 server using the as-supplied executable running in a Win98SE VirtualBox, which needs a Ctrl-C shutdown & restart cycle every 24 hours (sooner sometimes if there's a lock-up). I also have two identical PuppyLinux 4.xx systems in each of their own VirtualBox PCs, running a locally-compiled base binary for their old Linux v2.6 (IIRC): one has been running for 5 days, currently chewing 7% mem; and, _this_ system has been going for 43 days, using 10% mem.

    Hope it helps...

    Cheers,
    Paul.

    ... What are you looking down here for? Read the message.
    --- GoldED+/LNX 1.1.5-b20110213
    * Origin: Quinn's Rock vBox - sunny side up on the bookcase (3:640/1384)
  • From Björn Felten@2:203/2 to Matt Bedynek on Thu Sep 22 10:51:40 2016
    Do you sometimes have to restart it?

    Never, for more than a decade now.

    If it runs for a few weeks how much memory does it consume?

    I don't remember how long it's been running now (restart due to a power outage), but it's a matter of months. Precent memory consumtion 1340kB.


    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Tommi Koivula@2:221/6 to Matt Bedynek on Thu Sep 22 19:30:08 2016
    On 22.9.2016 9:30, Matt Bedynek : All :

    In the past I have observed some memory leaks in jamnntpd. I run the
    smapi version where as others run the original base but I am curious
    how stable has your release been? Do you sometimes have to restart
    it? How long does it run before it dies. If it runs for a few weeks
    how much memory does it consume?

    I'm running two jamnntpd's, under OS/2 and under Windows 2003 32bit. The
    OS/2 version is compiled with gcc-3/emx and the win version is compiled
    with cygwin gcc-3 from the linux source.

    The jamnntpd/cygwin has been running 13 days now, right now it uses 3,8M
    RAM, peak mem usage 7M.

    I have not noticed any mem leaks, but how would I know...

    No smapi.

    'Tommi

    ---
    * Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)
  • From Tommi Koivula@2:221/360 to Björn Felten on Thu Sep 22 19:43:46 2016
    On 22.9.2016 11:51, Bj”rn Felten : Matt Bedynek :

    Do you sometimes have to restart it?
    Never, for more than a decade now.

    Quite a long uptime! :D

    If it runs for a few weeks how much memory does it consume?
    I don't remember how long it's been running now

    uptime.exe \\COW
    \\COW has been up for: 13 day(s), 10 hour(s), 45 minute(s), 21 second(s)

    'Tommi

    --- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.
    * Origin: *** nntp://rbb.bbs.fi *** Lake Ylo *** Finland *** (2:221/360)
  • From Björn Felten@2:203/2 to Tommi Koivula on Thu Sep 22 19:38:47 2016
    uptime.exe \\COW
    \\COW has been up for: 13 day(s), 10 hour(s), 45 minute(s), 21 second(s)

    R:\binkd>uptime.exe \\DELL
    'uptime.exe' is not recognized as an internal or external command,
    operable program or batch file.




    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Tommi Koivula@2:221/1.1 to Björn Felten on Thu Sep 22 21:00:40 2016
    Hi Bj”rn.

    22 Sep 16 19:38, you wrote to me:

    R:\binkd>> uptime.exe \\DELL
    'uptime.exe' is not recognized as an internal or external command, operable program or batch file.

    Oh boy. Check your insecure inbound. ;)

    'Tommi

    ---
    * Origin: p1.f1.n221.z2.dyn.binkp.net (2:221/1.1)
  • From Björn Felten@2:203/2 to Tommi Koivula on Thu Sep 22 20:12:42 2016
    Oh boy. Check your insecure inbound. ;)

    Thanks!

    S:\FD\NETFILES>uptime.exe \\DELL
    \\DELL has been up for: 51 day(s), 6 hour(s), 14 minute(s), 28 second(s)




    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Matt Bedynek@1:19/10 to Paul Quinn on Thu Sep 22 18:01:36 2016
    On Thu, 22 Sep 2016 22:40:32 +1000, Paul Quinn wrote:

    I have three systems going 24/7. There's a Win32 server using the as-supplied executable running in a Win98SE VirtualBox, which needs a Ctrl-C shutdown & restart cycle every 24 hours (sooner sometimes if there's a lock-up). I also have two identical PuppyLinux 4.xx systems
    in each of their own VirtualBox PCs, running a locally-compiled base binary for their old Linux v2.6 (IIRC): one has been running for 5 days, currently chewing 7% mem; and, _this_ system has been going for 43 days, using 10% mem.

    Hope it helps...

    The percentage lost seems to depend on how busy a server is. I run
    two servers - one for nntp and the other for nntps. Do you run the
    smapi version? I doubt anyone else does since I could not get it to
    post messages without crashing when I started running it. But
    otherwise, the behavior you cite is similar to what I saw with my
    modified version so I believe there are issues to hunt down.

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Matt Bedynek@1:19/10 to Bj÷rn Felten on Thu Sep 22 18:02:22 2016
    On Thu, 22 Sep 2016 15:51:40 +0200, Björn Felten wrote:

    I don't remember how long it's been running now (restart due to a
    power outage), but it's a matter of months. Precent memory consumtion 1340kB.

    Do you have a way to monitor memory usage per process for when it was
    started vs over a time period?

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Matt Bedynek@1:19/10 to Tommi Koivula on Thu Sep 22 18:07:22 2016
    On Fri, 23 Sep 2016 00:30:08 +0300, Tommi Koivula <sysop@rbb.bbs.fi>
    wrote:

    I'm running two jamnntpd's, under OS/2 and under Windows 2003 32bit. The OS/2 version is compiled with gcc-3/emx and the win version is compiled with cygwin gcc-3 from the linux source.

    The jamnntpd/cygwin has been running 13 days now, right now it uses 3,8M RAM, peak mem usage 7M.

    I have not noticed any mem leaks, but how would I know...

    No smapi.

    You would simply need to watch the memory usage from start with
    respect to time. So, get initial value then check again after a week
    then two.

    I'll need to test building under cygwin. Havent done that yet

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Paul Quinn@3:640/384 to Matt Bedynek on Fri Sep 23 09:33:52 2016
    Hi! Matt,

    On 22 Sep 16 18:01, you wrote to me:

    The percentage lost seems to depend on how busy a server is.

    -This- Win98SE (128Mb RAM, BTW) VirtualBox's server is the busiest by far, with 5-7 regular users doing multiple logins over a 24 hour cycle. OTOH, Windows 9x-anything was always notorious as a 'server'.

    The other Puppy systems (256Mb RAM) have a single user only. :)

    I run two servers - one for nntp and the other for nntps. Do you run
    the smapi version? I doubt anyone else does since I could not get it
    to post messages without crashing when I started running it.

    Not currently. I checked back through this echo and back in April 2006, when I transitioning between Squish & JAM areas (in fact a reversal of a previous switch), I used the SMAPI version. I gave up when I wasn't running any public Squish areas, or even the Msg netmail area. I didn't like doing it anyway as I couldn't find a way of signalling my tosser whenever any mail was posted.

    But otherwise, the behavior you cite is similar to what I saw with my modified version so I believe there are issues to hunt down.

    Ah-so.

    Cheers,
    Paul.

    ... Highest message #: 943432. Message # last read: 59.
    --- Paul's Win98SE VirtualBox
    * Origin: Quinn's Post - Maryborough, Queensland, OZ (3:640/384)
  • From Björn Felten@2:203/2 to Matt Bedynek on Fri Sep 23 03:45:42 2016
    Do you have a way to monitor memory usage per process for when it was started vs over a time period?

    Yes, but 1340kB after 50 days would indicate that there's no memory leakage, don't you think?



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Tommi Koivula@2:221/6 to Matt Bedynek on Fri Sep 23 16:48:18 2016

    You would simply need to watch the memory usage from start with
    respect to time. So, get initial value then check again after a week
    then two.

    Right. Lets do that.

    ---
    * Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)
  • From Tommi Koivula@1:19/10 to Bj÷rn Felten on Fri Sep 23 08:51:34 2016
    Björn Felten - Matt Bedynek wrote:

    Do you have a way to monitor memory usage per process for when it
    was started vs over a time period?

    Yes, but 1340kB after 50 days would indicate that there's no memory leakage, don't you think?

    Well, maybe not. What if you restart the server, what is the memory
    usage then?

    'Tommi

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Matt Bedynek@1:19/10 to Bj÷rn Felten on Fri Sep 23 19:57:16 2016
    On Fri, 23 Sep 2016 08:45:42 +0200, Björn Felten wrote:

    Yes, but 1340kB after 50 days would indicate that there's no memory leakage, don't you think?

    Do you run the SSL version? I run two copies (1 for SSL). The
    problem really was noticed there so it could be related to that.

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Björn Felten@2:203/2 to Matt Bedynek on Sat Sep 24 10:43:21 2016
    Do you run the SSL version?

    Negatory.

    I run Johan's latest release.



    ..

    --- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
    * Origin: news://eljaco.se (2:203/2)
  • From Tommi Koivula@2:221/6 to Matt Bedynek on Fri Oct 7 09:49:30 2016
    I have not noticed any mem leaks, but how would I know...

    You would simply need to watch the memory usage from start with
    respect to time. So, get initial value then check again after a week
    then two.

    Ok, jamnntpd/cygwin32 has been running about two weeks now, no crashes,
    no restarts.

    mem peak
    24.09 3588k 5120k
    25.09 468k 5120k
    29.09 3848k 5120k
    01.10 2616k 6684k
    02.10 3516k 6684k
    07.10 4200k 6684k

    'Tommi

    ---
    * Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6.0)
  • From Matt Bedynek@1:19/10 to Tommi Koivula on Tue Oct 11 01:11:12 2016
    On Fri, 7 Oct 2016 14:49:30 +0300, Tommi Koivula <tommi@rbb.bbs.fi>
    wrote:

    mem peak
    24.09 3588k 5120k
    25.09 468k 5120k
    29.09 3848k 5120k
    01.10 2616k 6684k
    02.10 3516k 6684k
    07.10 4200k 6684k

    That doesn't look too bad. Do you get a lot of usage?

    On my non-SSL side am seeing a fair amount of usage from robots--which
    I might start blocking... once they outlive their usefulness!

    09-Oct-16 18:51:47 (76.72.175.251:37408) Connection established to findthatfile.com
    09-Oct-16 18:51:47 (76.72.175.251:37408) Connection slot 1 of 10
    09-Oct-16 18:51:47 (76.72.175.251:37408) < GROUP +ACCCESS&SUPPORT+
    09-Oct-16 18:51:47 (76.72.175.251:37408) Open JAM msgbase "./local/accesssupport"
    09-Oct-16 18:51:47 (76.72.175.251:37408) < GROUP 10th_amd
    09-Oct-16 18:51:47 (76.72.175.251:37408) Open JAM msgbase
    "./fido/10th_amd"
    09-Oct-16 18:51:47 (76.72.175.251:37408) < HEAD 159
    09-Oct-16 18:51:47 (76.72.175.251:37408) < ARTICLE 159
    09-Oct-16 18:51:47 (76.72.175.251:37408) < HEAD 160
    09-Oct-16 18:51:48 (76.72.175.251:37408) < ARTICLE 160
    09-Oct-16 18:51:48 (76.72.175.251:37408) < HEAD 161
    09-Oct-16 18:51:48 (76.72.175.251:37408) < ARTICLE 161
    09-Oct-16 18:51:48 (76.72.175.251:37408) < HEAD 162
    09-Oct-16 18:51:48 (76.72.175.251:37408) < ARTICLE 162
    09-Oct-16 18:51:48 (76.72.175.251:37408) < HEAD 163
    09-Oct-16 18:51:48 (76.72.175.251:37408) < ARTICLE 163
    09-Oct-16 18:51:48 (76.72.175.251:37408) < HEAD 164
    09-Oct-16 18:51:49 (76.72.175.251:37408) < ARTICLE 164
    09-Oct-16 18:51:49 (76.72.175.251:37408) < HEAD 165
    09-Oct-16 18:51:49 (76.72.175.251:37408) < ARTICLE 165
    09-Oct-16 18:51:49 (76.72.175.251:37408) < HEAD 166
    09-Oct-16 18:51:49 (76.72.175.251:37408) < ARTICLE 166
    09-Oct-16 18:51:49 (76.72.175.251:37408) < HEAD 167
    09-Oct-16 18:51:49 (76.72.175.251:37408) < ARTICLE 167
    09-Oct-16 18:51:49 (76.72.175.251:37408) < HEAD 168
    09-Oct-16 18:51:49 (76.72.175.251:37408) < ARTICLE 168
    09-Oct-16 18:51:50 (76.72.175.251:37408) < HEAD 169
    ... goes for ever

    Note, I have extra logging in what I use here because I have been
    debugging... but "findthatfile.com" literally walked every article of
    every group I have available.... :-/

    Good thing is that it is good test of the how well the code works!

    I am leaning toward believing the issue I see here is related to the
    TLS code since that instance is growing in usage much more so than the
    non-SSL instance.

    Need to get better with using valgrind!

    How are you guys on Win32 building versions of jamnntpd? Cygwin?

    ---
    * Origin: The Byte Museum - news: news.bytemuseum.org (1:19/10)
  • From Tommi Koivula@2:221/6 to Matt Bedynek on Tue Oct 11 16:41:30 2016
    Hi Matt.

    11 Oct 16 01:11, you wrote to me:

    On Fri, 7 Oct 2016 14:49:30 +0300, Tommi Koivula <tommi@rbb.bbs.fi>
    wrote:

    mem peak
    24.09 3588k 5120k
    25.09 468k 5120k
    29.09 3848k 5120k
    01.10 2616k 6684k
    02.10 3516k 6684k
    07.10 4200k 6684k

    That doesn't look too bad. Do you get a lot of usage?

    The string "Connection closed" shows 89 times in the log of yesterday. I don't normally do debug logging.

    09-Oct-16 18:51:47 (76.72.175.251:37408) Connection established to findthatfile.com

    Looks familiar. ;) I have these in my jamnntpd.allow file:

    #findthatfile:
    76.72.175.251 - -
    199.187.125.26 - -

    I am leaning toward believing the issue I see here is related to the
    TLS code since that instance is growing in usage much more so than the non-SSL instance.

    There is nntps://fidonews.mine.nu thru stunnel, but for example Thunderbird doesn't like my self-signed certificate. Sylpheed works ok.

    'Tommi

    ---
    * Origin: *** nntp://fidonews.mine.nu *** Finland *** (2:221/6)
  • From mark lewis@1:3634/12.73 to Matt Bedynek on Thu Oct 13 13:29:46 2016

    11 Oct 16 01:11, you wrote to Tommi Koivula:

    Note, I have extra logging in what I use here because I have been debugging... but "findthatfile.com" literally walked every article of every group I have available.... :-/

    yes, they are a file database service... they hunt down links for files and post them in their search results when people search for files... i have communicated with them in the past and this is what they told me... sometimes, depending on traffic, i just add their IP to my block list in my firewall and cut them off at the knees until i decide to allow them back in again... seems that they come by once every few months but yes, they do gather every post looking for file links...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... "Parser? Parsnip? - What's the difference?" W. Erickson
    ---
    * Origin: (1:3634/12.73)