Fri, 8 Aug 2003 12:38:14 -0700 (PDT)
Also, how do you handle libevent?
Do you build libevent with epoll, even if the kernel doesn't support it?
Because libevent selects poll/select/epoll/kqueue at runtime, it's best to
build the most powerful libevent as possible, so users can upgrade their
In my experience, building the kernel with epoll is way easier than fixing
all the userspace headers.
How does Gentoo handle all that? Is epoll* syscalls in the glibc headers
you guys distribute?
(note to others: memcached runs fine with poll/select. you don't need to
rebuild your kernel. but it's pretty cool if you do.)
On Fri, 8 Aug 2003, Lisa Marie Seelye wrote:
> On Fri, 2003-08-08 at 15:06, Brad Fitzpatrick wrote:
> > Thoughts on the Gentoo memcached roadmap:
> > * The APIs shouldn't RDEPEND on memcached. In LiveJournal's case, our
> > memcached machines are on totally separate hosts from our web nodes.
> I had debated this with myself before I put the ebuilds in. I came to
> the conclusion that memcached is not a large package, and it compiles
> very quickly.
> It isn't too much of a big deal; I'll remove the depends.
> > * I'd like the init/conf scripts included in memcached. It's not so much
> > that I'm lazy, but I'm not sure the correct way to do it. I'd just
> > write it in Perl, but probably wouldn't fly with most people.
> The init scripts are in the image of Bash, so we can't use Perl.
> > However it is, we need to support multiple processes in the conf file.
> > For instance, we have a 12 GB machine where we run 5x2 GB processes,
> > leaving 2 GB on the machine for other stuff. Because it's a 32 bit
> > machine, we can't just run 1 10 GB process.
> This seems like a candidate for program enhancement:
> memcached -d --servers 5 --mem 2048 = 5 servers at 2048MB each.
> Mainly because I don't particularly relish the job of modifying the init
> script. ;-) I'll see what I can do...
> <Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>