This is the mail archive of the
mailing list for the GCC project.
Re: Bounce GCC119 (was: [cfarm-admins] Extremely Slow Disk Access On GCC119)
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: noloader at gmail dot com
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sun, 10 Sep 2017 23:21:19 +0200
- Subject: Re: Bounce GCC119 (was: [cfarm-admins] Extremely Slow Disk Access On GCC119)
- Authentication-results: sourceware.org; auth=none
- References: <CAH8yC8kVhFk9ZZ6EbiscTKd-Rw8QNhzO0MZq-QAgZWWD7FUpTw@mail.gmail.com>
On Sun, Sep 10, 2017 at 10:42 PM, Jeffrey Walton <firstname.lastname@example.org> wrote:
> Hi David,
>> The system was configured to maximize diskspace and flexibility. It
>> now is supporting six, separate VMs. The disk array was configured as
>> a single physical volume, mapped to a single logical volume, that then
>> is partitioned into virtual I/O devices mapped to the VMs, which then
>> are formatted for AIX filesystems. It's a lot of virualization
>> layers. I already have increased the disk queues in the AIX VMs, which
>> increased performance relative to the initial installation. Also, the
>> VIOS was slightly under-sized for the current amount of usage, but I
>> have avoided rebooting the entire system to adjust that.
> I can't speak for others, but if GCC119 needs a reboot then do it.
The issue is not rebooting gcc119 AIX VM or wiping out the AIX /home
filesystem. To expand the VIOS partition I need to reboot the
hypervisor host and all of the AIX partitions, which is more difficult
to schedule. Also, there does not appear to be a mechanism to squeeze
down the physical volume on the disk array and carve out new devices.