From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RItIS-0005MN-Li for garchives@archives.gentoo.org; Wed, 26 Oct 2011 02:32:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E356421C18B; Wed, 26 Oct 2011 02:32:40 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 9477321C03D for ; Wed, 26 Oct 2011 02:31:45 +0000 (UTC) Received: from mail-gy0-f181.google.com ([209.85.160.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RItHN-003dYC-8f for gentoo-user@lists.gentoo.org; Wed, 26 Oct 2011 09:31:45 +0700 Received: by gye5 with SMTP id 5so1436379gye.40 for ; Tue, 25 Oct 2011 19:31:41 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.68.39.34 with SMTP id m2mr3415770pbk.75.1319596301600; Tue, 25 Oct 2011 19:31:41 -0700 (PDT) Received: by 10.142.127.2 with HTTP; Tue, 25 Oct 2011 19:31:40 -0700 (PDT) Received: by 10.142.127.2 with HTTP; Tue, 25 Oct 2011 19:31:40 -0700 (PDT) In-Reply-To: <4EA767D6.4060303@badapple.net> References: <4EA767D6.4060303@badapple.net> Date: Wed, 26 Oct 2011 09:31:40 +0700 Message-ID: Subject: Re: [gentoo-user] Re: How to record memory usage & bandwidth usage? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=bcaec52161a9cdc96c04b02a7485 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: X-Archives-Hash: 3cc26036c88bf07543397894634d62dc --bcaec52161a9cdc96c04b02a7485 Content-Type: text/plain; charset=UTF-8 On Oct 26, 2011 8:55 AM, "kashani" wrote: > > On 10/25/2011 6:27 PM, Pandu Poluan wrote: >> >> (Sorry for the late reply; somehow this thread got lost in the mess) >> >> On Oct 12, 2011 2:03 AM, "James" > > wrote: >> >> > >> > Pandu Poluan poluan.info > writes: >> > >> > >> > > The head honcho of my company just asked me to "plan for migration of >> > > X into the cloud" (where "X" is the online trading server that our >> > > investors used). >> > >> > This is a single server or many at different locations. >> > If a WAN monitoring is what you are after, along with individual >> > server resources, you have many choices. >> > >> >> It's a single server that's part of a three-server system. The server >> needs to communicate with its 2 cohorts continuously, so I have to >> provision enough backhaul bandwidth from the cloud to my data center. >> >> In addition to provisioning enough RAM and CPU, of course. >> >> > > Now, I need to monitor how much RAM is used throughout the day by X, >> > > also how much bandwidth gets eaten by X throughout the day. >> > >> > Most of the packages monitor ram as well as other resource utilization >> > of the servers, firewall, routers and other SNMP devices in your network. >> > some experimentation may be warranted to find what your team likes best. >> > >> >> Currently I've settled on a simple solution: run dstat[1] with nohup 30 >> minutes before 1st trading session, stop it 30 minutes after 2nd trading >> session, and send the CSV record via email. Less intrusion into the >> system (which the Systems guys rightly have reservations of). >> > > You're not going to be happy with this design for a couple of reasons. > > 1. It's more expensive that your current setup. If the two servers at your datacenter are down I assume the server is the cloud is useless and vice versa. You already have to maintain infrastructure for those two servers so you're realizing no savings by eliminating on server from your infrastructure. Buying a $1500 rack server amortized over three years is a better deal than paying for equivalent power in the cloud. > > 2. Latency. You're increasing it. > > 3. Cloud performance varies. Networks split, machines run slow, it happens. You'll have more consistent performance on your own machines. It's getting better, but it's still something with which to be aware. > > Migrating to virtual servers makes some sense, but you need to look at it on a case by case basis. > > kashani > Indeed. The fact is that the server-to-be-clouded is a trading server used by approx. 3000+ clients (investors). Our 20 Mbps line is barely able to cater them all, and my company has to pay through the nose for each additional Mbps. How big a nose? I'm looking at the quotation on my desk that says my.company needs to shell out 200 USD (excl tax) per additional Mbps per month... The traffic between that server and the other 2 is less than 20 Mbps, but how much less, that's what I'm trying to find out. As to latency... the "powers that be" had decided that, "... sucks to be trading on your own; better to go through our dealers... " :-P Rgds, --bcaec52161a9cdc96c04b02a7485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 26, 2011 8:55 AM, "kashani" <kashani-list@badapple.net> wrote:
>
> On 10/25/2011 6:27 PM, Pandu Poluan wrote:
>>
>> (Sorry for the late reply; somehow this thread got lost in the mes= s)
>>
>> On Oct 12, 2011 2:03 AM, "James" <wireless@tampabay.rr.com
>> <mailto:wireless@ta= mpabay.rr.com>> wrote:
>>
>> =C2=A0>
>> =C2=A0> Pandu Poluan <pandu <at> poluan.info <http://poluan.= info>> writes:
>> =C2=A0>
>> =C2=A0>
>> =C2=A0> > The head honcho of my company just asked me to &qu= ot;plan for migration of
>> =C2=A0> > X into the cloud" (where "X" is the= online trading server that our
>> =C2=A0> > investors used).
>> =C2=A0>
>> =C2=A0> This is a single server or many at different locations.=
>> =C2=A0> If a WAN monitoring is what you are after, along with i= ndividual
>> =C2=A0> server resources, you have many choices.
>> =C2=A0>
>>
>> It's a single server that's part of a three-server system.= The server
>> needs to communicate with its 2 cohorts continuously, so I have to=
>> provision enough backhaul bandwidth from the cloud to my data cent= er.
>>
>> In addition to provisioning enough RAM and CPU, of course.
>>
>> =C2=A0> > Now, I need to monitor how much RAM is used throug= hout the day by X,
>> =C2=A0> > also how much bandwidth gets eaten by X throughout= the day.
>> =C2=A0>
>> =C2=A0> Most of the packages monitor ram as well as other resou= rce utilization
>> =C2=A0> of the servers, firewall, routers and other SNMP device= s in your network.
>> =C2=A0> some experimentation may be warranted to find what your= team likes best.
>> =C2=A0>
>>
>> Currently I've settled on a simple solution: run dstat[1] with= nohup 30
>> minutes before 1st trading session, stop it 30 minutes after 2nd t= rading
>> session, and send the CSV record via email. Less intrusion into th= e
>> system (which the Systems guys rightly have reservations of).
>>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0You're not going to be happy with this = design for a couple of reasons.
>
> 1. It's more expensive that your current setup. If the two servers= at your datacenter are down I assume the server is the cloud is useless an= d vice versa. You already have to maintain infrastructure for those two ser= vers so you're realizing no savings by eliminating on server from your = infrastructure. Buying a $1500 rack server amortized over three years is a = better deal than paying for equivalent power in the cloud.
>
> 2. Latency. You're increasing it.
>
> 3. Cloud performance varies. Networks split, machines run slow, it hap= pens. You'll have more consistent performance on your own machines. It&= #39;s getting better, but it's still something with which to be aware.<= br> >
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Migrating to virtual servers makes some sen= se, but you need to look at it on a case by case basis.
>
> kashani
>

Indeed.

The fact is that the server-to-be-clouded is a trading server used by ap= prox. 3000+ clients (investors). Our 20 Mbps line is barely able to cater t= hem all, and my company has to pay through the nose for each additional Mbp= s.

How big a nose? I'm looking at the quotation on my desk that says my= .company needs to shell out 200 USD (excl tax) per additional Mbps per mont= h...

The traffic between that server and the other 2 is less than 20 Mbps, bu= t how much less, that's what I'm trying to find out.

As to latency... the "powers that be" had decided that, "= ... sucks to be trading on your own; better to go through our dealers... &q= uot; :-P

Rgds,

--bcaec52161a9cdc96c04b02a7485--