til Otheus:
gprof-l complains om manglende handlingsknappen grafen data, som jeg ikke helt forstår, men det er utenfor poenget i denne tråden.

til Jim:

På SCO
$ Truss. / Tstloop
semsys (1, 2819742, 2, 0, 0, 0) \u003d 18827
semsys (0, 18827, 2, 6, 2147483024, 0) \u003d 0
.
.
.
gjentar videre og videre til 5.000.000 ganger, som kodes.
Jeg ser ikke noen brk her.

På Linux
$ Strace-TC. / Tstloop
tid sekunder usecs / ringe samtaler feil 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 åpne
0,00 0,000028 14 2 fstat64
0,00 0,000025 13 2 lukke
0,00 0,000020 20 1 munmap
0,00 0,000018 18 1 lest
0,00 0,000018 18 1 uname
0,00 0,000018 18 1 stat64
0,00 0,000014 14 1 1 tilgang
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 total

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>
.
.
.

Betyr dette output tydeliggjør noe?

Otheus --
utimes er samtalen gjort av Det gir kumulativt for bruker og kjernemodus, samt cum prosessen veggen tid.
Kaller det for en start sett av verdier og en sluttid sett av verdier, og deretter subtrahere for deltaet verdi.

Jeg tror du er forvirret. utime () og utimes () operere på en inode å endre tidsstempler filer.

Beklager - litt spor - Jeg ser ikke hvor OP har forsøkt å kjøre ltrace med syscalls aktivert - eller strace.

Forskjellene sannsynligvis skyldes OS gjennomføringen - kanskje en rekke samtaler til brk i en OS og ikke den andre. Det er verdt 2 minutter det tar å utføre Otheus' koden under strace på hver boks. Det ville utelukke et odde kernel innstilling eller noen implementering "-funksjon" som rotårsak av forskjellene. Hvis du ser merkelig oppførsel, som mye av systemet anrop på en boks og ikke på den andre, kanskje noen kan relatere det til noe nyttig.

For å være klar, fikk du prøve "gprof-p-l"?


Også, ifølge nettstedetKan du kjøre "truss-c" på SCO å få lignende sammendrag resultater. Hvis vi er heldige, får du per-systemet ringe tid, som vist ovenfor ved ltrace-TC på Linux. Da kan du få det vi virkelig etter - hvor mye tid som gjør Linux bruker i hvert system ringe versus SCO.

SCO har kernel parameter problemer med semphores. SHMMAX parameter som standard er liten. Dette er et kjent problem. Her er SCO docset for installering Postgres som omtaler det.

Administrerer Kjerne Resources

Det er retninger for å se på SHMMAX innstillingen. Hvis det er standard, kan du vurdere å øke verdien og se om det løser delt minne problemer du har.

Otheus --

Du er riktig - ganger () bruker struct tms ikke utimes (). Det var min dårlige.

Jim, du tror at størrelsen på SHMxxx parametere påvirker resultatene?

Migurus,

Hva gjør du har angitt for Linux delte innstillinger? "/ sbin / sysctl-a | grep shm". (Ignorer feil). Sammenlign disse til hva som er satt for SCO (jeg vet ikke hvordan jeg skal få dem).