Hi Mike, That's what it does when it stops serving requests.
And yes ruby on a T2000 is a bad idea, ruby needs faster chips. Also there's DTrace-enabled Ruby at https://dev.joyent.com/projects/ruby-dtrace/wiki/Ruby+DTrace if you'd like to go deeper. Regards, Jason On May 1, 2008, at 5:55 AM, Mika Borner wrote: > Hi > > We are hosting a ruby on rails application for a customer. We first > run the application on a T2000 and single thread performance sucked. > > Because of tight schedules we moved the app to an X2100, and > performance seems ok so far. > > Anyway, I'm trying to find out where the bottleneck is, and run a > dtrace to count the system calls for the mongrel process. > > It seems there are a lot of setcontext/nanosleep syscalls when > issuing an http request. Can anybody explain me shortly, what these > system calls do? I tried to google them up, but couldn't find an > explanation that I'mable to understand :-) > > dtrace -n 'syscall:::entry/execname == "mongrel_rails"/ > { @[probefunc] = count() }' > dtrace: description 'syscall:::entry' matched 233 probes > ^C > > fsat 1 > getpid 1 > accept 2 > access 2 > getdents64 2 > getpeername 2 > ioctl 2 > rename 2 > unlink 3 > connect 4 > doorfs 4 > fxstat 4 > mmap 4 > munmap 4 > sigaction 4 > so_socket 4 > getuid 6 > open 6 > open64 7 > read 10 > times 16 > write 18 > fstat64 19 > lstat64 19 > stat64 20 > close 22 > llseek 25 > fcntl 33 > recv 108 > send 108 > gtime 300 > lwp_sigmask 537 > pollsys 640 > nanosleep 8489 > setcontext 58846 > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > [email protected] _______________________________________________ dtrace-discuss mailing list [email protected]
