kets in 'CLOSED' state.
Even if the incoming queue isnt read entirely a call to close should
close it. Also I really can't find any documentation in netstat, or
elsewhere, about the 'CLOSED' state...
Any help would greatly be appreciated!
Kind Regards,
Ali Ni
states: 6.2% user, 0.0% nice, 62.6% system, 7.5% interrupt, 23.8%
idle
Mem: 698M Active, 27M Inact, 209M Wired, 440K Cache, 96M Buf, 1068M Free
Swap: 512M Total, 512M Free
Are there anymore quite stable things to do ? That is except for upping to
current, which I frankly feel is too dangerous..
oil down to a scheduler being to slow (or the
context switching) for these amounts of processes waiting/blocking ? If so
could it be an idea to put blocking processes into a special queue in which
the scheduler adepts simple scheduling algorithm (such as first come fi
changes to improve the performance of the scheduler in the presence
> of threads, etc.
if all else fails i'll start doing this, thanks for the suggestion!
--
Ali Niknam <[EMAIL PROTECTED]> | tel 0182-504424 | fax 0182-504460
Transip B.V. | http://www.transip.nl/ | Mensen met vers
figured it was some kind of lock/block/mutex/whatever inside
the kernel
Best Regards,
Ali Niknam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ueue).
I would be very interested to hear what this problem could be; perhaps i can
test a little if someone has solutions (i cant test much unfortunately,
it's a production system).
Best Regards,
Ali Niknam
___
[EMAIL PROTECTED] mailing list
http
6 matches
Mail list logo
