<div dir="ltr">powerpc is a good cpu<div>AIX.. well i know it a litte bit but even IBM doesn't like it anymore (lot of stuff under powerpc but not under AIX, spectrum scale and other ibm slideware)</div><div><br></div><div>some time you get more powerhorse under a RHEL/PowerPC than AIX/PowerPC even with the IBM AIX support... it's life and like other sysadmin we go to the best OS when we have choice ;)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-19 20:56 GMT+01:00 Yuri Voinov <span dir="ltr"><<a href="mailto:yvoinov@gmail.com" target="_blank">yvoinov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br></span>
AIX great system in good hands. ;)<br>
<br>
All the matter in the gasket between the seats and the console. :D<br>
<br>
20.12.15 1:53, Jean Christophe Ventura пишет:<br>
<span style="white-space:pre-wrap"><span class="">> Well<br>
><br>
> If it was my project : archlinux using yaourt and each needed
package<br>
> compiled in a VM<br>
><br>
> I work at a company as sysadmin and proxy aren't in my side
(network<br>
> things...)<br>
> So if i can configure a repository or sync a repository with
the response :<br>
> go head it will be here for years.., if not i have to deal
with distrib<br>
> package :P<br>
><br>
> Even in a VM i prefered a debian server than a RHEL<br>
> By the way the good thing it's not a AIX proxy ;)<br>
><br></span><div><div class="h5">
> I do not understand the love of archaeological fossils. It
repositories<br>
> such junk lying around? :-D<br>
><br>
> 20.12.15 0:56, Jean Christophe Ventura пишет:<br>
> > Hi,<br>
><br>
> > I'm currently working to migrate RHEL5 2.7 Squid to
RHEL7 3.3.<br>
><br>
> > I have migrated the config files to be 3.3 compliant
(CIDR, remove of<br>
> > deprecated function,change cache from UFS to AUFS)
without any change<br>
> > (cache mem, policy, smp)<br>
><br>
> > The new platform is a 4 node R610 (24 proc
hyperthreading activate)<br>
> > with 48GB of RAM, only 143GB disk in RAID for OS and
cache. Each node<br>
> > is connected to the network using 2x1Gbit bonding 2/3
level (some<br>
> > network port are available on the server).<br>
><br>
> > bandwidth allocated for Internet users 400Mbit<br>
><br>
> > The difference between the old plateform and the new one
doesn't seem<br>
> > to be very fantastic :P<br>
> > I have read the mailing list history alot.<br>
><br>
> > Squid release:<br>
> > So i know 3.3 isn't anymore maintain but this
infrastructure will be<br>
> > not maintain by myself and i don't think that people
behind will do<br>
> > the update them self<br>
> > If a official repository exist, maybe this question will
be reopen<br>
> > (from what i have read it's more some of you build
packages from<br>
> > source and give them to people)<br>
><br>
> > Squid auth:<br>
> > It's transparent/basic auth only filtering some ip with
acl.<br>
><br>
> > Squid bandwidth:<br>
> > Currently a squid node treat something like 30/50Mbit
(information<br>
> > recovered using iftop)<br>
> > From previous viewed mail i think it's normal for a
non-smp configuration<br>
><br>
> > Squid measure:<br>
> > [root at xxxx ~]# squidclient mgr:5min | grep
'client_http.requests'<br>
> > client_http.requests = 233.206612/sec<br>
> > other info<br>
> > Cache information for squid:<br>
> > Hits as % of all requests: 5min: 6.8%,
60min: 7.1%<br>
> > Hits as % of bytes sent: 5min: 4.7%,
60min: 4.4%<br>
> > Memory hits as % of hit requests: 5min:
21.4%, 60min: 21.5%<br>
> > Disk hits as % of hit requests: 5min: 34.7%,
60min: 30.8%<br>
> > Storage Swap size: 9573016 KB<br>
> > Storage Swap capacity: 91.3% used, 8.7% free<br>
> > Storage Mem size: 519352 KB<br>
> > Storage Mem capacity: 99.1% used, 0.9% free<br>
> > Mean Object Size: 47.71 KB<br>
><br>
> > Now question and advise :<br>
><br>
> > This metrics seem too low for me. anyone of you agree ?<br>
><br>
> > 4 node x 50Mbit node= 200Mbit<br>
> > To treat the maxbandwidth (400Mbit) + the lost of one
host i need to<br>
> > configure 4 thread by node.<br>
> > Is there any reason or brillant idea for more (i will
have some core<br>
> > still available) ? calculation too empirical ?<br>
><br>
> > This url
<a href="http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster" target="_blank">http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster</a><br>
> > seem to be a good start :P<br>
> > Using this method i can interconnect each proxy to share
their cache<br>
> > (maybe using dedicated network port). Usefull or not ?
may this<br>
> > increase the hit ratio ? if this idea is'nt stupid
interconnet using<br>
> > the frontend only or directy to each ?<br>
><br>
> > For now i have :<br>
> > - 100GB of disk available for cache<br>
> > - 40GB of RAM (let 8 for OS + squid disk cache related
ram usage)<br>
><br>
> > 1 front with the RAM cache and 4 back with disk cache.<br>
> > AUFS or ROCK cache? mix of them ? 50% each ? maybe
another rules ?<br>
> > (i think it's will be linked to the cache content but
any advise or<br>
> > method is welcome)<br>
><br>
> > I can get more speed and/or space for disk cache using
SAN, do you<br>
> > know if the data is sequential or random ?<br>
><br>
> > Any advise/rules to increase the hit ratio ? :)<br>
> > Any general advise/rules ?<br>
><br>
> > Thanks for your help<br>
><br>
><br>
> > Jean Christophe VENTURA<br>
> > _______________________________________________<br>
> > squid-users mailing list<br>
> > squid-users at <a href="http://lists.squid-cache.org" target="_blank">lists.squid-cache.org</a><br>
> > <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
></div></div></span><div><div class="h5"><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br></div></div>
iQEcBAEBCAAGBQJWdbZlAAoJENNXIZxhPexGrRoH/3c+Fdii20mZJQplh5iayrQY
<br>
H2oQwYJhSw4S61NonryqPTLAxgfa8Q2De7LCpfhk52vWUvNk27WSRekQFEbs8mNO
<br>
AHthD1uNegGg0rJqLyRmLdPEArECtyTFSg7sZADWFenUphxHjYZZKPrz3qEb357X
<br>
pjA2PrNOo2i8bKVtDlTQP/mElnUoHSWG+GJWf/CROiB5/hUdwcyfagkTyB8mjqFo
<br>
b0FYj+d0KT4mtawWLOoIa06S1cIeUUVsyHGcodqD9rwTsNjKI3QiXWQFwCi+ToAf
<br>
Jrk1958Q3QjvqOaiYpCGAwpaeU7K02Prsa3WclLtud0gvXuDSq9uhI65Z32XyAQ=
<br>
=sIHo
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</div>
</blockquote></div><br></div>