X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C2DE952CB2 for ; Fri, 19 Aug 2005 20:02:40 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 05681-09 for ; Fri, 19 Aug 2005 23:02:36 +0000 (GMT) Received: from smtp106.mail.sc5.yahoo.com (smtp106.mail.sc5.yahoo.com [66.163.169.226]) by svr1.postgresql.org (Postfix) with SMTP id 7C89952B6D for ; Fri, 19 Aug 2005 20:02:35 -0300 (ADT) Received: (qmail 86809 invoked from network); 19 Aug 2005 23:02:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=1OToURhp9PxWy6HIdRVIavt+C59i+wcyRtNCFkXeA3GBrqajs+NcNQkPc5WoHrEYBhMYsOvQ+df5uJRtiAbGp/R3r85PBggLlTJ1J3pLMDCRLWcEPrfrqp7R8SoAFansDwd1yH7JGGY7BCyuIzYqXC91s00EtkHmK0VsKSr13r4= ; Received: from unknown (HELO ?10.3.101.47?) (mcotner@24.248.72.254 with login) by smtp106.mail.sc5.yahoo.com with SMTP; 19 Aug 2005 23:02:37 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 19 Aug 2005 19:02:35 -0400 Subject: Re: sustained update load of 1-2k/sec From: Mark Cotner To: PFC , Tom Lane , Bob Ippolito Cc: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.374 required=5 tests=[DNS_FROM_RFC_ABUSE=0.374] X-Spam-Level: X-Archive-Number: 200508/285 X-Sequence-Number: 14032 :) Most of the ppl on this list are systems programmers, however I am not. The tool of choice for this app is Ruby and the libraries don't support async SNMP at the moment. I've done a good deal of async snmp and the libraries that actually pull it off generally aren't that good(Net-SNMP and Perl's Net::SNMP). Granted, UDP is connectionless to an extent, but you still have to send the PDU, and bind to the return socket and wait. If you batch the outgoing PDUs then you can get away with sending them out synchronously and listening on the returning socket synchronously, but it would require that your libraries support this. I understand the concepts well enough, maybe I'll put together a patch. It would be much lower overhead than managing all those threads. Looks like it's gonna be a fun weekend. Thanks again for all the great feedback. 'njoy, Mark On 8/19/05 2:11 PM, "PFC" wrote: > >> While I agree that hundreds of threads seems like overkill, I think the >> above advice might be going too far in the other direction. The problem >> with single-threaded operation is that any delay affects the whole >> system --- eg, if you're blocked waiting for disk I/O, the CPU doesn't > > You use UDP which is a connectionless protocol... then why use threads ? > > I'd advise this : > > Use asynchronous network code (one thread) to do your network stuff. This > will lower the CPU used by this code immensely. > Every minute, dump a file contianing everything to insert into the table. > Use another thread to COPY it into the DB, in a temporary table if you > wish, and then INSERT INTO ... SELECT. > This should be well adapted to your requirements. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster