-
Was sind schon 500ms wenn der Job selber schon wesentlich länger braucht?
Und wenn dann ggf. noch Jobs in der Queue hängen ...
Ich glaube, das kann man getrost vernachlässigen.
-
Zitat von Fuerchau
Was sind schon 500ms wenn der Job selber schon wesentlich länger braucht?
Und wenn dann ggf. noch Jobs in der Queue hängen ...
Ich glaube, das kann man getrost vernachlässigen .
Baldur, wenn in den Queues für das SBS mal eben 100 Jobs (kleinerer Bauart) rumtummeln, geht schon mal ne Minute für das Aufstarten drauf. Und vielleicht 20 Sekunden fürs Verarbeiten. Das ist schon relevant...
-h
-
... das ist zwar lange her, dass das meine Baustelle war, das dürfte aber eher an den MAXJOBS des Subsystems liegen...
D*B
Zitat von holgerscherer
Alles eine Frage der Literzahl. Aber einer gewissen Menge ist i5/OS aber mehr mit sich selbst als mit den Jobs beschäftigt. Hier auf einer der öffentlichen Kisten hat jeder User seine eigene JobQ (also etwa 15.000) samt Einträge in die Subsysteme. Das Starten eines Jobs (sprich - suchen des Eintrags in den JOBQE) kann schon mal 500ms brauchen... bei 2000CPW
-h
-
Zitat von BenderD
... das ist zwar lange her, dass das meine Baustelle war, das dürfte aber eher an den MAXJOBS des Subsystems liegen...
D*B
Nö, nicht die Bohne. Das liegt daran, dass die Suche in der JOBQE Liste schon seit Jahren lahm ist. So ab 3000 Einträgen merklich ;-)
-h
-
Zitat von holgerscherer
Baldur, wenn in den Queues für das SBS mal eben 100 Jobs (kleinerer Bauart) rumtummeln, geht schon mal ne Minute für das Aufstarten drauf. Und vielleicht 20 Sekunden fürs Verarbeiten. Das ist schon relevant...
-h
Ich sehe eher das Problem in den Systemwerten:
QACTJOB *ALC Anfängliche Anzahl aktiver Jobs
QADLACTJ *ALC Zusätzliche Anzahl aktiver Jobs
QADLTOTJ *ALC Zusätzliche Anzahl aller Jobs
QTOTJOB *ALC Anfängliche Gesamtzahl Jobs
Damit läßt sich für das Starten und Verwalten von Jobs eine ganze Menge Performance erzeugen.
Wenn ich mich recht erinnere liegen die Vorgabewerte bei 20/10/10/30. Das bedeutet, bei 100 neuen Jobs im System, dass die JOBTBL etwa 3 mal um 30 Einträge (im ungünstigsten Fall 4 mal) erweitert werden muss. Dabei spielt die "Bauart" der Jobs keine Rolle, die vorgehensweise des OS ist immer gleich.
Bei 15000 Benutzern und nur 2000 CPWs würde ich mich spontan für mindestens 6 SBSDs entscheiden, damit jedes SBS nur etwa 2500 bis 3000 Jobs verwalten muss.
Für die Systemwerte würde ich 30/20/20/50 einstellen.
Wobei diese Einstellungen stark von der Größe des Hauptspeichers abhängen, da jeder aktive Job Minimum 110k belegt.
Gruß
Thomas
-
Zitat von TGsoft
Ich sehe eher das Problem in den Systemwerten:
Leute, bei aller Liebe - bitte noch mal genau lesen. Hier gehts um den SBMJOB, ursprünglich aus der Frage, QBASE oder QCTL. Wir weichen davon ein wenig ab. Ich kann meine gesamte Job-Konfig sowie die zugehörigen Systemwerte automatisiert umbauen auf 2 SBS oder 20SBS (schon probiert). Das bringt nicht wirklich viel. Nur - wenn die Anzahl der JOBQE in einem Subsystem etwa 3000 übersteigt - geht das System merklich in die Knie. Wie viele Jobs da gleichzeitig laufen, und ob der Hausmeister die Spools in die Tonne kippt, ist nebensächlich.
-h
-
Das Hauptproblem des OS/400 ist, dass die Suchvorgänge für JOBQ's sequentiell laufen.
Zum besorgen eines freien Job-Eintrages muss auch die Jobverwaltungstabelle intern sequentiell durchsucht werden.
Sicherlich spielen obige Systemwerte noch eine kleine Rolle, aber wenn man mal mit WRKSYSSTS sieht, wieviele tote Jobs so im System sind, kann man die Zeiten wohl nachvollziehen.
Bei meinem Kunden gibts z.B. nur 1200 aktive Jobs bei 21.000 Jobs im System!
Die Differenz sind Jobs, die halt irgendwo noch Spools aufheben.
Zusätzlich wird auch das Erstellen von Spools dadurch verlangsamt, da auch hier nach freien Spoolblöcken sequentiell gesucht wird.
Eine effektivere Speicherverwaltung (wobei das OS/400 hier schon erheblich besser ist als z.B. Windows) beim Durchsuchen mittels Userindizees würde da schon einiges helfen.
Warum die IBM da nicht mal was macht, müsste man diese mal fragen.
Vielleicht rechnet die immer noch nicht damit, dass man eine AS/400 auch als Mainframe benutzen kann.
Aber wie schon mal gesagt, am eigentlichen Thema vorbei.
-
@Baldur
Vielleicht am Thema vorbei, aber immer wieder interessant.
GG
-
-
Zitat von AS400.lehrling
Der stand Verantwortliche für das Systen i sagte ganz locker "Vom OS/400 haben wir uns achon vor langer Zeit innerlich verabschiedet"
Ist ja auch richtig, denn die Zukunft heißt: IBM i
-
Zitat von Pikachu
Ist ja auch richtig, denn die Zukunft heißt: IBM i
Ja, man darf das nicht so heiss essen, wie es irgend ein Anzugträger auftischt. Zwischenzeitliche Gerüchte aus dubioser Ecke haben auch AIX schon ins Reich der Toten verbannt. Lebt trotzdem noch.
Die Roadmap geht mindestens bis 2017 - und zwischenzeitlich wird auch noch V8 vorgestellt ;-)
-h
Similar Threads
-
By madoxx in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 04-10-10, 08:20
-
By csantner in forum IBM i Hauptforum
Antworten: 26
Letzter Beitrag: 12-05-10, 11:09
-
By SL in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 03-05-05, 07:00
-
By JonnyRico in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 03-08-02, 13:59
-
By Frank.Sobanek in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 08-08-01, 16:05
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks