22 Apr
2014
22 Apr
'14
10:47 a.m.
Hi all,
after updating my two instances (my university's build server and PMBS)
here is my first impression:
The update went more or less smooth.
+ with 2.5.1 the db update runs through without any error - thank you,
Adrian!
- README.UPDATERS still has the task to db:migrate the webui DB, which
does not exist anymore (bee github #650)
- the search in the web frontend does not work, thinking sphinx seems
not being able to talk to the database
- the system is catastrophically slow, and I mean "slow" with a
capital "S"!
Compared with the performance of 2.4.6 it seems to need the triple
amount of CPU, and four times disk IO - these data come from PMBS.
Is there someone, who has tried to downgrade to 2.4.6 again, and is
this possible at all, apart from replaying a backup?
Greetings,
Stefan
--
Stefan Botter
Network Manager
Jacobs University Bremen gGmbH
Campus Ring 1 | 28759 Bremen | Germany
Commercial registry: Amtsgericht Bremen, HRB 18117
CEO / Geschäftsführerin: Prof. Dr.-Ing. Katja Windt
Chair Board of Governors: Prof. Dr. Karin Lochte
22 Apr
22 Apr
11:14 a.m.
On Dienstag, 22. April 2014, 10:47:56 wrote Stefan Botter:
Hi all,
after updating my two instances (my university's build server and PMBS)
here is my first impression:
The update went more or less smooth.
+ with 2.5.1 the db update runs through without any error - thank you,
Adrian!
- README.UPDATERS still has the task to db:migrate the webui DB, which
does not exist anymore (bee github #650)
dropped now.
- the search in the web frontend does not work,
thinking sphinx seems
not being able to talk to the database
If you have the config/production.sphinx.conf file, a simple
rake ts:index ts:start
should index and start the searchd . The original idea was that clockworkd
is starting it ....
- the system is catastrophically slow, and I mean
"slow" with a
capital "S"!
Compared with the performance of 2.4.6 it seems to need the triple
amount of CPU, and four times disk IO - these data come from PMBS.
Do you speak about api, scheduler, worker or what ?
Is there someone, who has tried to downgrade to 2.4.6
again, and is
this possible at all, apart from replaying a backup?
I doubt that the db rollback will work that far....
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG
Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
3:55 p.m.
Hi Adrian,
On Tue, 22 Apr 2014 11:14:21 +0200
"Adrian Schröter" <adrian(a)suse.de> wrote:
PMBS is running everything except a worker, so mysql, api, src_server,
rep_server, signer, scheduler, dispatcher. Please see the attached
images from pnp4nagios. I updated PMBS on Apr 19th, and around 3 pm the
system started to burn ...
The system is a 8GB, 4CPU VM in vCenter, on a OK-performing RAID10 of
14 disks.
Thought so, but I will secure my backup from 2.4.6 to be able to go
back - for the time being.
Another thing: where do I report setup issues with the appliance to?
Github, or Bugzilla?
Greetings,
Stefan
--
Stefan Botter
Network Manager
Jacobs University Bremen gGmbH
Campus Ring 1 | 28759 Bremen | Germany
Commercial registry: Amtsgericht Bremen, HRB 18117
CEO / Geschäftsführerin: Prof. Dr.-Ing. Katja Windt
Chair Board of Governors: Prof. Dr. Karin Lochte
On Dienstag, 22. April 2014, 10:47:56 wrote Stefan
Botter:
Great! The search works now. Will it start automatically the next time
I boot the machine and start up the services?
- the search in the web frontend does not work,
thinking sphinx
seems not being able to talk to the database
If you have the config/production.sphinx.conf file, a simple
rake ts:index ts:start
should index and start the searchd . The original idea was that
clockworkd is starting it .... - the system
is catastrophically slow, and I mean "slow" with a
capital "S"!
Compared with the performance of 2.4.6 it seems to need the
triple amount of CPU, and four times disk IO - these data come from
PMBS.
Do you speak about api, scheduler, worker or what ? Is there
someone, who has tried to downgrade to 2.4.6 again, and is
this possible at all, apart from replaying a backup?
I doubt that the db rollback will work that far.... 
4:02 p.m.
On Dienstag, 22. April 2014, 15:55:49 wrote Stefan Botter:
Hi Adrian,
On Tue, 22 Apr 2014 11:14:21 +0200
"Adrian Schröter" <adrian(a)suse.de> wrote:
PMBS is running everything except a worker, so mysql, api, src_server,
rep_server, signer, scheduler, dispatcher. Please see the attached
images from pnp4nagios. I updated PMBS on Apr 19th, and around 3 pm the
system started to burn ...
hm, a bit more detailed debug logs would be needed. If it is just the delayed
jobs for example, it might be that just the data update/scanning jobs do have some
more long running work directly after the update. But it will go away ...
Can you check which processes do use the CPU/IO mostly?
Maybe an strace on that might be helpful.
On Dienstag, 22. April 2014, 10:47:56 wrote
Stefan Botter:
Great! The search works now. Will it start automatically the next time
I boot the machine and start up the services?
- the search in the web frontend does not work,
thinking sphinx
seems not being able to talk to the database
If you have the config/production.sphinx.conf file, a simple
rake ts:index ts:start
should index and start the searchd . The original idea was that
clockworkd is starting it .... - the
system is catastrophically slow, and I mean "slow" with a
capital "S"!
Compared with the performance of 2.4.6 it seems to need the
triple amount of CPU, and four times disk IO - these data come from
PMBS.
Do you speak about api, scheduler, worker or what ? The system is a 8GB, 4CPU VM in vCenter, on a
OK-performing RAID10 of
14 disks.
Thought so, but I will secure my backup from 2.4.6 to be able to go
back - for the time being.
Another thing: where do I report setup issues with the appliance to?
Github, or Bugzilla?
Greetings,
Stefan
github is fine.
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG
Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org
Is there
someone, who has tried to downgrade to 2.4.6 again, and is
this possible at all, apart from replaying a backup?
I doubt that the db rollback will work that far....
25 Apr
25 Apr
2:03 p.m.
Hi Adrian,
On Tue, 22 Apr 2014 16:02:13 +0200
"Adrian Schröter" <adrian(a)suse.de> wrote:
On Dienstag, 22. April 2014, 15:55:49 wrote Stefan
Botter:
The schedulers for i586 and x86_64 seem to burn a lot more CPU cycles
than compared to 2.4.6, and this results in more I/O.
If Henne is near you, he may help in having a more direct look at the
machine, else please tell me, what I should look for.
Greetings,
Stefan
--
Stefan Botter
Network Manager
Jacobs University Bremen gGmbH
Campus Ring 1 | 28759 Bremen | Germany
Commercial registry: Amtsgericht Bremen, HRB 18117
CEO / Geschäftsführerin: Prof. Dr.-Ing. Katja Windt
Chair Board of Governors: Prof. Dr. Karin Lochte
PMBS is running everything except a worker, so
mysql, api,
src_server, rep_server, signer, scheduler, dispatcher. Please see
the attached images from pnp4nagios. I updated PMBS on Apr 19th,
and around 3 pm the system started to burn ...
hm, a bit more detailed debug logs would be needed. If it is just the
delayed jobs for example, it might be that just the data
update/scanning jobs do have some more long running work directly
after the update. But it will go away ...
Can you check which processes do use the CPU/IO mostly?
Maybe an strace on that might be helpful.
2466
days inactive
2469
days old
buildservice@lists.opensuse.org
4 comments
2 participants
participants (2)
-
Adrian Schröter -
Stefan Botter