Min versjon av truss har ikke-c flagg eller andre flagg ligner på en jeg brukte med spor under Linux.


På Linux:
$ / Sbin / sysctl-a | grep shm
... <snip feil msgs>
vm.hugetlb_shm_group \u003d 0
kernel.shmmni \u003d 4096
kernel.shmall \u003d 2097152
kernel.shmmax \u003d 33554432

Q: Hvorfor vil SHM parametere påvirker semaforen ytelse?

Og bare i tilfelle jeg kjørte dette
$ / Sbin / sysctl-a | grep sem
<snip feil msgs>
kernel.sem \u003d 250 32000 32 128

* Possibly * på grunn av antall sidevisninger tabeller og strukturer som kreves for å gjøre bruk av alle som minne. Det kan resultere i hver op krever to til tre cache savner per samtale. Hvis det ikke er noen buffer tilløp, fordi shmem er mindre, så kanskje det tar 3 ganger så fort. Jim?

Jeg vil be gurus Hvor ellers kan jeg legge inn spørsmålet mitt. Vil du anbefale meg noen annen gruppe eller et forum?
Dine forslag vil bli verdsatt.

Som jeg tidligere har antydet: LinuxQuestions.org.

Siden flaskehals synes å være innenfor systemet ringe, foreslår jeg at du også se på Kjerne-relaterte BB's (KernelTrap.org er en god en).

Takk Otheus og Jim, jeg har ganske detaljert svar her:
semaforen tilgang hastighet | KernelTrap

Så, den 2.6.9 kernel er ikke den beste for moderne h / w.

Jeg setter pris everebodys gang!

Kudos til deg for fasthet! Men jeg tror ikke dette er slutten av den.

Jeg gjorde et lite forskning på strcmp svar. 2.6.9 ble utgitt i 2004 og er standard med RHEL 4, som leveres med glibc 2.3.4. Pentium 3's var gammel i 2004. RHEL 5 skip med kernel 2.6.18 og glibc 2.5.12.

Så jeg gjorde noen tester.

Jeg fulgte strcmp's forslag og brukt en "fallende tidtaker"-metoden, der loop starter og ender etter tid () kaller notater en endring i sekunder. Det er en 10 til 100 ms variansen på begge sider av høsten, så jeg tok et gjennomsnitt av flere kjører. Da jeg dele OPS / s nummer av CPU-hastighet (sykluser / s) for å få "tics per op".

• 2.6.18 / P3 / 800 MHz: 548300 / s (gjennomsnittlig 19 kjøres) \u003d 1459 tics / op
• 2.6.18 / AMD Opteron 285 / 2,6 GHz: 1689138 (avg 6 driver) \u003d 1539 tics / op
• 2.6.18 / AMD Opteron 270 / 1,0 GHz: 974228 (avg 7 kjøres) \u003d 1026 tics / op
• 2.6.9 / Xeon / 3.6 GHz: 917196 (avg, 4 kjører) \u003d 3925 tics / op
• 2.6.9 / P3 / 1,25 GHz: 733927 (avg, 5 driver) \u003d 1703 tics / op
• 2.6.9 / Xeon / 2.3 GHz: 1127894 (avg, 10 løper) \u003d 2608 tics / op

For tics / op mindre er bedre. Så 2.6.18 kjernen er faktisk raskere enn 2.6.9 kjerner. Den Xeon er mye saktere. Antagelig den kjerner ble utarbeidet av en lavest fellesnevneren. Ingen optimaliseringsprogrammet flaggene ble aktivert, men det var en forskjell i kompilatorene: the 2.6.9 vert brukt gcc 3.4.6, mens de nyere som var med gcc 4.1.1. Dessuten bør det nevnes at vi ikke har en AMD kjører 2.6.9 eller Xeon kjører 2.6.18.

Det svært godt kan være at problemet er at disse kjerner ikke var sammensatt optimalt for de ulike arkitekturer. Hvorfor Xeons er så mye lavere er ganske overraskende, gitt sitt karakteristiske bruk som HPC komponenter.

Uansett, ingen av disse resultatene synes å forklare grunnleggende spørsmål: Hvorfor er SCO mye raskere?

Her er min kode:

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2

/* change this per CPU to run between 8 and 12 s*/
const static int maxloop = 10000000; 

main(int argc, char *argv[])
{
    time_t start,last,stop;
    long int i;
    int estimate = 100;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    key = ftok("/tmp",99);
    last=start=time(NULL);
    for (i = 0; i < 1000; ++i) {
        usleep(10);
        last=time(NULL);
        if (last > start) break;
    }
    start=last;
    last = 0;

    for (i = maxloop/8; i < maxloop; i++) {
      if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
          perror("Can Not Get Semaphore ID");
      }
      if (semctl(sid, NSEMS, GETALL, vals) == -1) {
          perror("Can Not Get Semaphore Values");
      }
    }

/* do the last 1/8th until the second changes.
    If your processor reaches the maxloop before that,
    change the maxloop or the divisor or the "estimate" */

    stop=time(NULL);
    for (i = maxloop - maxloop/8; i < maxloop; ++i) {
      if ( !(i % estimate) ) {
        last=time(NULL);
        if (last > stop) break;
        stop=last;
      }

      /* repeat semaphore opts */
      if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
          perror("Can Not Get Semaphore ID");
      }
      if (semctl(sid, NSEMS, GETALL, vals) == -1) {
          perror("Can Not Get Semaphore Values");
      }
    }
    stop=last;

    printf("%.2f semop/s (%i/%i) [%d]\n", (double)i/(stop-start), i, stop-start, estimate);
}