til Otheus:
gprof-l klager over manglende call-graf data, som jeg ikke helt forstå, men det er ud over det punkt i denne tråd.

til Jim:

På SCO
$ Spærfag. / Tstloop
semsys (1, 2819742, 2, 0, 0, 0) \u003d 18827
semsys (0, 18827, 2, 6, 2147483024, 0) \u003d 0
.
.
.
gentages om og om til 5.000.000 gange, som kodes.
Jeg kan ikke se nogen brk her.

På Linux
$ Strace-Tc. / Tstloop
tid sekunder usecs / opkald opkald fejl syscall
------ ----------- ----------- --------- --------- ---- ------------
50,85 62,145774 29 2134526 semctl
49,15 60,059067 28 2134527 semget
0,00 0,000088 18 5 old_mmap
0,00 0,000054 18 3 mprotect
0,00 0,000039 20 2 åbne
0,00 0,000028 14 2 fstat64
0,00 0,000025 13 2 tæt
0,00 0,000020 20 1 munmap
0,00 0,000018 18 1 læses
0,00 0,000018 18 1 uname
0,00 0,000018 18 1 stat64
0,00 0,000014 14 1 1 adgang
0,00 0,000014 14 1 set_thread_area
0,00 0,000012 12 1 gang
0,00 0,000008 8 1 brk
------ ----------- ----------- --------- --------- ---- ------------
100,00 122,2051 97 4269075 1 samlede

når jeg prøver
$ Strace. / Tstloop
semget (1660977153, 2, IPC_CREAT | 0777) \u003d 32769 <0.000028>
semctl (32769, 2, IPC_64 | GETALL, 0xfeead064) \u003d 0 <0.000029>
.
.
.

Er dette output præciserer noget?

Otheus --
utimes er opfordringen fra Det giver kumulative gange for brugeren og kerne samt cum proces væg tid.
Kalder det for et begyndende sæt af værdier og et sluttidspunkt sæt af værdier, og derefter trække i en delta værdi.

Jeg tror, du er forvirret. utime () og utimes () opererer på en inode at ændre tidsstemplerne af filer.

Beklager - en smule off spor - Jeg kan ikke se, hvor OP har prøvet at køre ltrace med syscalls aktiveret - eller strace.

Forskellene sandsynligvis skyldes OS gennemførelse - måske en masse opkald til brk i en OS og ikke den anden. Det er værd 2 minutter det tager at udføre Otheus' kode under strace på hver boks. Det ville udelukke et ulige kerne indstilling eller nogle gennemførelse "funktion" som den egentlige årsag til forskellene. Hvis du ser mærkelig adfærd, ligesom en masse system opfordrer en kasse og ikke på den anden side, måske er der nogen kan relatere det til noget nyttigt.

Blot for at være klar, har du prøve "gprof-p-l"?


Også ifølge denne side, Kan du køre "spærfag-c" på SCO at få lignende resumé resultater. Hvis vi er heldige, får du per-system vagtperiode, som vist ovenfor ved ltrace-Tc på Linux. Så kan du få, hvad vi virkelig efter - hvor meget tid der går Linux bruger i hvert system opkald versus SCO.

SCO har kerne parameter spørgsmål med semphores. SHMMAX parameter som standard er lille. Dette er et kendt problem. Her er SCO docset til installation Postgres at diskuterer det.

Administrerende Kernel Ressourcer

Der er anvisninger til visning af SHMMAX indstilling. Hvis det er standard, overveje at hæve værdien og se om det løser den delte hukommelse, problemer du har.

Otheus --

du er korrekte - gange () bruger struct TMS ikke utimes (). Det var mit dårlige.

Jim, tænker du på, at størrelsen af SHMxxx parametre påvirker effektivitet?

Migurus,

Hvad mener du har indstillet for din Linux delt hukommelse indstillinger? "/ sbin / sysctl-a | grep shm". (Ignorer fejl). Sammenlign dem til, hvad der er fastsat for SCO (Jeg ved ikke, hvordan man får dem).