| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: CSS (Eclipse and Phoebus) super slow on a server with multiple users |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Jokinen Antti (F4E)" <Antti.Jokinen at f4e.europa.eu> |
| Cc: | "Sancho Duarte Andre \(F4E-Ext\)" <Andre.Sancho at ext.f4e.europa.eu>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Wed, 1 Dec 2021 08:57:57 -0800 |
On 11/29/21 5:27 AM, Jokinen Antti (F4E) wrote: > On the other hand we managed to improve the remote server performance significantly by updating the kernel plus enabling VT-X on the virtualization software. FYI according to "#sar -d" the average await parameter was ~2000ms before whereas now it's always <30ms. Additionally now the server seems not to struggle under a heavy load anymore and for example in the remote user point of view, all programs are evenly responsive/unresponsive. What is "#sar -d"? "average await" sounds like a disk metric? Is this related to eg. https://linux.die.net/man/1/atopsar I ask because I've run into odd performance regressions with software running in VMs before, and struggled to understand what was going on. So I'm interested in knowing what you looked at before noticing that the vt-x CPU extension wasn't being used? eg. one thing I look for on Linux+QEMU is if the VM process opens "/dev/kvm". (and obviously whether "/dev/kvm" exists)