should migrate package-import.ubuntu.com onto standard centrally-managed hardware

Bug #605018 reported by Martin Pool
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Distributed Development
Confirmed
High
Unassigned

Bug Description

At the moment the package-importer is on a really large machine that's a twin of the landscape database server. IS would like us to move this off this machine; at the same time perhaps we can make it a more standard losa service.

This requires:

 * checking whether it actually needs an unusually large machine
 * allocating a new machine (needs an rt)
 * migration
 * handing off any special privileges from james_w to losas

Martin Pool (mbp)
summary: - should migrate package-importer onto standard centrally-managed software
+ should migrate package-importer onto standard centrally-managed hardware
Revision history for this message
Martin Pool (mbp) wrote : Re: should migrate package-importer onto standard centrally-managed hardware

james_w says: fine cpu wise, is using quite a lot of memory, don't know about io load. does use a lot of disk but much of it can be deleted.

summary: - should migrate package-importer onto standard centrally-managed hardware
+ should migrate package-import.ubuntu.com onto standard centrally-managed
+ hardware
Revision history for this message
Martin Pool (mbp) wrote :

After some brief inspection with elmo of jubany: it's bursting large amounts of IO which are quite quick because it has 16 spindles, but the average rate is pretty low. Moving it would go from 32GB ram to 6GB (though with the option to add more), and that may be enough. There's 240GB of disk used, which is more than the typical server, but if some of that is cache we may be able to cope.

Unless someone else screams, elmo will pick a time to move it, giving a few days notice to ~canonical-bzr and the udd list.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 605018] Re: should migrate package-import.ubuntu.com onto standard centrally-managed hardware

JFDI please!

Revision history for this message
John A Meinel (jameinel) wrote :

I think part of it is that the managing script always runs 8-concurrent imports (probably to match the 8-cpus). I don't know if it needs to be running that quickly, and that would probably lower the peak memory consumption, etc.

Martin Pool (mbp)
Changed in udd:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Vincent Ladeuil (vila) wrote :

As a data point, nexuiz-data currently hang (for yet unknown reasons) while using 4.6G.

There is obviously a bug there but this doesn't mean the 4.6G are not needed either.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.