1

I'm writing a daemon for a newsletter in Perl.

The daemon will be running 24/7 on the server. It'll have an active connection to postgresql database almost all the time.

I don't have that much experience with Perl so I would love if some of you can share information about the following:

  1. How to limit the RAM. I don't want to get out of ram. As I said this program will be running all the time as a daemon without being stopped.

  2. What should I be aware of when writing such daemons ?

DVK
  • 126,886
  • 32
  • 213
  • 327
tftd
  • 16,203
  • 11
  • 62
  • 106
  • 1
    There's a perl daemon tutorial here, but doesn't specify which Perl it's for, so might be a bit dated: http://www.webreference.com/perl/tutorial/9/ – Marc B Feb 11 '11 at 17:30
  • I've seen that but I prefer using Proc::Daemon. Is there any big difference ? :) – tftd Feb 11 '11 at 17:52

3 Answers3

5

  1. As far as SQL connection - make sure you don't leak memory. Retrieve the least amount of data you need from the query, and ensure that the data structures storing the data go out of scope immediately so garbage collector can reclaim them

    Please note that there may be memory leaks you have no control over (e.g. in Postgresql connectivity code). It's been known to happen. The best solution for that problem (short of doing precise memory profiling and fixing the leaks in underlying libraries) is for your daemon to pull a Phoenix - stop doing what it's doing and exec() a new copy of itself.

  2. As far as writing Perl daemons, some resources:

DVK
  • 126,886
  • 32
  • 213
  • 327
  • I'm using this Proc::Daemon->new() for the daemon. Will that be a problem if I make the pgsql connection not persistent and undef the variable holding the connection? – tftd Feb 11 '11 at 17:51
  • 1
    That depends entirely on what kind of memory leak may exist (one one exists). Some can be fixed this way. Some can't and require a "full process reboot" - e.g. if the leak is in XS C code. – DVK Feb 11 '11 at 17:54
  • So in this case i would need to kill unix process of the perl script and start it again right? – tftd Feb 11 '11 at 18:56
  • 1
    Nope - you can `exec()` the process (this replaces existing process with the new one) or `fork` and kill off the parent. – DVK Feb 11 '11 at 20:39
2

Regarding #1: Perl is garbage collected.

The effective meaning of that is you should ensure all references to data are cleaned up when you are done with them, thus allowing the garbage collector to run.

http://perldoc.perl.org/perlobj.html#Two-Phased-Garbage-Collection

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
  • Yes I "undef" all of the variables except the db connection which needs to be active all the time... – tftd Feb 11 '11 at 17:44
  • 1
    That's the possible problem - you **might** conceivably have a memory leak in DB connection object (including in XS code). Not very likely, but not inconceivable. – DVK Feb 11 '11 at 17:48
  • Ok if I make it not persistent and undef it every time I stop using it would that fix the possible problem ? – tftd Feb 11 '11 at 17:53
  • Objects might be leaked if they are put into a hash table, and not referenced anywhere else. – maxelost Feb 11 '11 at 19:06
  • @maxelost: why do you say that? Perl's GC is only reference based. If they're not referenced anywhere else, they cannot leak. – Ashley Feb 11 '11 at 20:58
  • @Ashley: I mean that if one forgets that e.g. a hash table keeps references to some objects, then they will not become GC-ed. Some languages provide weak references to address this problem (I don't know whether Perl does). – maxelost Feb 11 '11 at 23:37
1

One thing to watch for are memory leaks. There’s a very nice thread about memory leaks in Perl already on SO.

Community
  • 1
  • 1
zoul
  • 102,279
  • 44
  • 260
  • 354