<div dir="ltr">Hoi,<div>Nice in theory. However tools DO die when others produce too much shit for the server to handle.</div><div><br></div><div>In my mind the most important thing is for Labs to be operational. Worrying about dimes and cents is too expensive when it is at the cost of a diminished service to Labs users. </div>

<div><br></div><div>Yes, even when performance is always ensured it pays to target bad practices because sure as hell, some things do need improvements and it pays to make sure that software gets optimised.</div><div>Thanks,</div>

<div>     GerardM</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 May 2014 09:39, Petr Bena <span dir="ltr"><<a href="mailto:benapetr@gmail.com" target="_blank">benapetr@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">what about doing some steps to optimize current resource usage so that<br>
it's not needed to put more and more money to increase the HW<br>
resources?<br>
<br>
for example I believe there is a number of tools that are using nfs<br>
servers in insane way, for example generating tons of temporary data<br>
that could be instead stored to /tmp instead of /data/project also the<br>
static binaries that are in /data/project could be probably cached in<br>
memory somehow so that they don't need to be loaded over network<br>
everytime the task restart.<br>
<br>
Perhaps installing sar-like monitoring tool on nfs server would help<br>
to discover which tool uses the nfs most and such a report could help<br>
developers of these tools to figure out where is a need for<br>
optimization. I myself have some idea of how labs work so my own tools<br>
are usually very optimized to use these network resources (and even<br>
disk storage) as less as possible, but others might not be aware of<br>
that and may need some help optimizing these.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, May 23, 2014 at 6:28 PM, Marc A. Pelletier <<a href="mailto:marc@uberbox.org">marc@uberbox.org</a>> wrote:<br>
> Hello everyone,<br>
><br>
> In the following week or two, we are planning on adding another bound<br>
> network port to increase the NFS server's bandwidth (which is,<br>
> currently, saturating at regular interval).<br>
><br>
> This will imply a short period of downtime (on the order of 10 minutes<br>
> or so) during which no NFS service will be provided.  In theory, this<br>
> will result in file access simply stalling and resuming at the end of<br>
> the outage, but processes that have timeouts may be disrupted (in<br>
> particular, web service access will likely report gateway issues during<br>
> that interval).<br>
><br>
> While this is not set in stone, I am aiming for Friday, May 30 at 18:00<br>
> UTC for the downtime.  I will notify this list with a confirmation or a<br>
> new schedule in at least three days in advance.<br>
><br>
> Thanks for your patience,<br>
><br>
> -- Marc<br>
><br>
> _______________________________________________<br>
> Labs-l mailing list<br>
> <a href="mailto:Labs-l@lists.wikimedia.org">Labs-l@lists.wikimedia.org</a><br>
> <a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-l</a><br>
<br>
_______________________________________________<br>
Labs-l mailing list<br>
<a href="mailto:Labs-l@lists.wikimedia.org">Labs-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-l</a><br>
</div></div></blockquote></div><br></div>