Hohe CPU-Auslastung mit CFS?


25

Ich habe in einer früheren Frage versucht, die Ursache für eine Zunahme der CPU-Auslastung beim Verschieben einer Anwendung von RHEL 5 auf RHEL 6 herauszufinden. Die Analyse, die ich durchgeführt habe, scheint darauf hinzudeuten, dass dies durch das CFS im Kernel verursacht wird. Ich habe eine Testanwendung geschrieben, um zu überprüfen, ob dies der Fall ist (die ursprüngliche Testanwendung wurde entfernt, um der Größenbeschränkung zu entsprechen, ist aber immer noch in Git Repo verfügbar) .

Ich habe es mit dem folgenden Befehl auf RHEL 5 kompiliert:

cc test_select_work.c -O2 -DSLEEP_TYPE=0 -Wall -Wextra -lm -lpthread -o test_select_work

Ich habe dann mit den Parametern gespielt, bis die Ausführungszeit pro Iteration auf einem Dell Precision m6500 etwa 1 ms betrug.

Ich habe das folgende Ergebnis auf RHEL 5 erhalten:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 911.5 us avg: 913.7 us max: 917.1 us stddev: 2.4 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1802.6 us avg: 1803.9 us max: 1809.1 us stddev: 2.1 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 7580.4 us avg: 8567.3 us max: 9022.0 us stddev: 299.6 us

Und das Folgende auf RHEL 6:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 914.6 us avg: 975.7 us max: 1034.5 us stddev: 50.0 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1683.9 us avg: 1771.8 us max: 1810.8 us stddev: 43.4 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 7997.1 us avg: 8709.1 us max: 9061.8 us stddev: 310.0 us

In beiden Versionen waren diese Ergebnisse ungefähr so, wie ich es erwartet hatte, wobei die durchschnittliche Zeit pro Iteration relativ linear skaliert wurde. Ich habe dann mit neu kompiliert -DSLEEP_TYPE=1und die folgenden Ergebnisse für RHEL 5 erhalten:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 1803.3 us avg: 1902.8 us max: 2001.5 us stddev: 113.8 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1997.1 us avg: 2002.0 us max: 2010.8 us stddev: 5.0 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 6958.4 us avg: 8397.9 us max: 9423.7 us stddev: 619.7 us

Und die folgenden Ergebnisse auf RHEL 6:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 2107.1 us avg: 2143.1 us max: 2177.7 us stddev: 30.3 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 2903.3 us avg: 2903.8 us max: 2904.3 us stddev: 0.3 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 8877.7.1 us avg: 9016.3 us max: 9112.6 us stddev: 62.9 us

Auf RHEL 5 waren die Ergebnisse ungefähr so, wie ich es erwartet hatte (4 Threads dauerten doppelt so lange, da 1 ms inaktiv waren, aber die 8 Threads dauerten genauso lange, da jeder Thread jetzt ungefähr die Hälfte der Zeit inaktiv ist, und immer noch ziemlich lang linearer Anstieg).

Mit RHEL 6 hat sich die mit 4 Threads benötigte Zeit jedoch um etwa 15% mehr erhöht als die erwartete Verdopplung, und der Fall mit 8 Threads hat sich um etwa 45% mehr erhöht als die erwartete leichte Zunahme. Die Zunahme des 4-Thread-Falls scheint zu sein, dass RHEL 6 tatsächlich für eine Handvoll Mikrosekunden länger als 1 ms schläft, während RHEL 5 nur ungefähr 900 us schläft, aber dies erklärt nicht die unerwartet große Zunahme der 8 und 40 Thread Fällen.

Ich sah ähnliche Verhaltensweisen bei allen 3 -DSLEEP_TYPE-Werten. Ich habe auch versucht, mit den Scheduler-Parametern in sysctl zu spielen, aber nichts schien einen signifikanten Einfluss auf die Ergebnisse zu haben. Irgendwelche Ideen, wie ich dieses Problem weiter diagnostizieren kann?

UPDATE: 2012-05-07

Ich habe Messungen der Benutzer- und System-CPU-Auslastung aus / proc / stat // tasks // stat als Ausgabe des Tests hinzugefügt, um zu versuchen, einen anderen Beobachtungspunkt zu erhalten. Ich habe auch ein Problem mit der Aktualisierung des Mittelwerts und der Standardabweichung festgestellt, das eingeführt wurde, als ich die äußere Iterationsschleife hinzufügte. Daher füge ich die neuen Diagramme hinzu, die den korrigierten Mittelwert und die korrigierten Standardabweichungsmessungen enthalten. Ich habe das aktualisierte Programm aufgenommen. Ich habe auch ein Git-Repo gemacht, um den Code zu verfolgen, und er ist hier verfügbar.

#include <limits.h>
#include <math.h>
#include <poll.h>
#include <pthread.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/syscall.h>
#include <sys/time.h>


// Apparently GLIBC doesn't provide a wrapper for this function so provide it here
#ifndef HAS_GETTID
pid_t gettid(void)
{
  return syscall(SYS_gettid);
}
#endif


// The different type of sleep that are supported
enum sleep_type {
  SLEEP_TYPE_NONE,
  SLEEP_TYPE_SELECT,
  SLEEP_TYPE_POLL,
  SLEEP_TYPE_USLEEP,
  SLEEP_TYPE_YIELD,
  SLEEP_TYPE_PTHREAD_COND,
  SLEEP_TYPE_NANOSLEEP,
};

// Information returned by the processing thread
struct thread_res {
  long long clock;
  long long user;
  long long sys;
};

// Function type for doing work with a sleep
typedef struct thread_res *(*work_func)(const int pid, const int sleep_time, const int num_iterations, const int work_size);

// Information passed to the thread
struct thread_info {
  pid_t pid;
  int sleep_time;
  int num_iterations;
  int work_size;
  work_func func;
};


inline void get_thread_times(pid_t pid, pid_t tid, unsigned long long *utime, unsigned long long *stime)
{
  char filename[FILENAME_MAX];
  FILE *f;

  sprintf(filename, "/proc/%d/task/%d/stat", pid, tid);
  f = fopen(filename, "r");
  if (f == NULL) {
    *utime = 0;
    *stime = 0;
    return;
  }

  fscanf(f, "%*d %*s %*c %*d %*d %*d %*d %*d %*u %*u %*u %*u %*u %Lu %Lu", utime, stime);

  fclose(f);
}

// In order to make SLEEP_TYPE a run-time parameter function pointers are used.
// The function pointer could have been to the sleep function being used, but
// then that would mean an extra function call inside of the "work loop" and I
// wanted to keep the measurements as tight as possible and the extra work being
// done to be as small/controlled as possible so instead the work is declared as
// a seriees of macros that are called in all of the sleep functions. The code
// is a bit uglier this way, but I believe it results in a more accurate test.

// Fill in a buffer with random numbers (taken from latt.c by Jens Axboe <jens.axboe@oracle.com>)
#define DECLARE_FUNC(NAME) struct thread_res *do_work_##NAME(const int pid, const int sleep_time, const int num_iterations, const int work_size)

#define DECLARE_WORK() \
  int *buf; \
  int pseed; \
  int inum, bnum; \
  pid_t tid; \
  struct timeval clock_before, clock_after; \
  unsigned long long user_before, user_after; \
  unsigned long long sys_before, sys_after; \
  struct thread_res *diff; \
  tid = gettid(); \
  buf = malloc(work_size * sizeof(*buf)); \
  diff = malloc(sizeof(*diff)); \
  get_thread_times(pid, tid, &user_before, &sys_before); \
  gettimeofday(&clock_before, NULL)

#define DO_WORK(SLEEP_FUNC) \
  for (inum=0; inum<num_iterations; ++inum) { \
    SLEEP_FUNC \
     \
    pseed = 1; \
    for (bnum=0; bnum<work_size; ++bnum) { \
      pseed = pseed * 1103515245 + 12345; \
      buf[bnum] = (pseed / 65536) % 32768; \
    } \
  } \

#define FINISH_WORK() \
  gettimeofday(&clock_after, NULL); \
  get_thread_times(pid, tid, &user_after, &sys_after); \
  diff->clock = 1000000LL * (clock_after.tv_sec - clock_before.tv_sec); \
  diff->clock += clock_after.tv_usec - clock_before.tv_usec; \
  diff->user = user_after - user_before; \
  diff->sys = sys_after - sys_before; \
  free(buf); \
  return diff

DECLARE_FUNC(nosleep)

{
  DECLARE_WORK();

  // Let the compiler know that sleep_time isn't used in this function
  (void)sleep_time;

  DO_WORK();

  FINISH_WORK();
}

DECLARE_FUNC(select)
{
  struct timeval ts;
  DECLARE_WORK();

  DO_WORK(
    ts.tv_sec = 0;
    ts.tv_usec = sleep_time;
    select(0, 0, 0, 0, &ts);
    );

  FINISH_WORK();
}

DECLARE_FUNC(poll)
{
  struct pollfd pfd;
  const int sleep_time_ms = sleep_time / 1000;
  DECLARE_WORK();

  pfd.fd = 0;
  pfd.events = 0;

  DO_WORK(
    poll(&pfd, 1, sleep_time_ms);
    );

  FINISH_WORK();
}

DECLARE_FUNC(usleep)
{
  DECLARE_WORK();

  DO_WORK(
    usleep(sleep_time);
    );

  FINISH_WORK();
}

DECLARE_FUNC(yield)
{
  DECLARE_WORK();

  // Let the compiler know that sleep_time isn't used in this function
  (void)sleep_time;

  DO_WORK(
    sched_yield();
    );

  FINISH_WORK();
}

DECLARE_FUNC(pthread_cond)
{
  pthread_cond_t cond  = PTHREAD_COND_INITIALIZER;
  pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
  struct timespec ts;
  const int sleep_time_ns = sleep_time * 1000;
  DECLARE_WORK();

  pthread_mutex_lock(&mutex);

  DO_WORK(
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_nsec += sleep_time_ns;
    if (ts.tv_nsec >= 1000000000) {
      ts.tv_sec += 1;
      ts.tv_nsec -= 1000000000;
    }
    pthread_cond_timedwait(&cond, &mutex, &ts);
    );

  pthread_mutex_unlock(&mutex);

  pthread_cond_destroy(&cond);
  pthread_mutex_destroy(&mutex);

  FINISH_WORK();
}

DECLARE_FUNC(nanosleep)
{
  struct timespec req, rem;
  const int sleep_time_ns = sleep_time * 1000;
  DECLARE_WORK();

  DO_WORK(
    req.tv_sec = 0;
    req.tv_nsec = sleep_time_ns;
    nanosleep(&req, &rem);
    );

  FINISH_WORK();
}

void *do_test(void *arg)
{
  const struct thread_info *tinfo = (struct thread_info *)arg;

  // Call the function to do the work
  return (*tinfo->func)(tinfo->pid, tinfo->sleep_time, tinfo->num_iterations, tinfo->work_size);
}

struct thread_res_stats {
  double min;
  double max;
  double avg;
  double stddev;
  double prev_avg;
};

#ifdef LLONG_MAX
  #define THREAD_RES_STATS_INITIALIZER {LLONG_MAX, LLONG_MIN, 0, 0, 0}
#else
  #define THREAD_RES_STATS_INITIALIZER {LONG_MAX, LONG_MIN, 0, 0, 0}
#endif

void update_stats(struct thread_res_stats *stats, long long value, int num_samples, int num_iterations, double scale_to_usecs)
{
  // Calculate the average time per iteration
  double value_per_iteration = value * scale_to_usecs / num_iterations;

  // Update the max and min
  if (value_per_iteration < stats->min)
    stats->min = value_per_iteration;
  if (value_per_iteration > stats->max)
    stats->max = value_per_iteration;
  // Update the average
  stats->avg += (value_per_iteration - stats->avg) / (double)(num_samples);
  // Update the standard deviation
  stats->stddev += (value_per_iteration - stats->prev_avg) * (value_per_iteration - stats->avg);
  // And record the current average for use in the next update
  stats->prev_avg= stats->avg;
}

void print_stats(const char *name, const struct thread_res_stats *stats)
{
  printf("%s: min: %.1f us avg: %.1f us max: %.1f us stddev: %.1f us\n",
      name,
      stats->min,
      stats->avg,
      stats->max,
      stats->stddev);
}

int main(int argc, char **argv)
{
  if (argc <= 6) {
    printf("Usage: %s <sleep_time> <outer_iterations> <inner_iterations> <work_size> <num_threads> <sleep_type>\n", argv[0]);
    printf("  outer_iterations: Number of iterations for each thread (used to calculate statistics)\n");
    printf("  inner_iterations: Number of work/sleep cycles performed in each thread (used to improve consistency/observability))\n");
    printf("  work_size: Number of array elements (in kb) that are filled with psuedo-random numbers\n");
    printf("  num_threads: Number of threads to spawn and perform work/sleep cycles in\n");
    printf("  sleep_type: 0=none 1=select 2=poll 3=usleep 4=yield 5=pthread_cond 6=nanosleep\n");
    return -1;
  }

  struct thread_info tinfo;
  int outer_iterations;
  int sleep_type;
  int s, inum, tnum, num_samples, num_threads;
  pthread_attr_t attr;
  pthread_t *threads;
  struct thread_res *res;
  struct thread_res **times;
  // Track the stats for each of the measurements
  struct thread_res_stats stats_clock = THREAD_RES_STATS_INITIALIZER;
  struct thread_res_stats stats_user = THREAD_RES_STATS_INITIALIZER;
  struct thread_res_stats stats_sys = THREAD_RES_STATS_INITIALIZER;
  // Calculate the conversion factor from clock_t to seconds
  const long clocks_per_sec = sysconf(_SC_CLK_TCK);
  const double clocks_to_usec = 1000000 / (double)clocks_per_sec;

  // Get the parameters
  tinfo.pid = getpid();
  tinfo.sleep_time = atoi(argv[1]);
  outer_iterations = atoi(argv[2]);
  tinfo.num_iterations = atoi(argv[3]);
  tinfo.work_size = atoi(argv[4]) * 1024;
  num_threads = atoi(argv[5]);
  sleep_type = atoi(argv[6]);
  switch (sleep_type) {
    case SLEEP_TYPE_NONE:   tinfo.func = &do_work_nosleep; break;
    case SLEEP_TYPE_SELECT: tinfo.func = &do_work_select;  break;
    case SLEEP_TYPE_POLL:   tinfo.func = &do_work_poll;    break;
    case SLEEP_TYPE_USLEEP: tinfo.func = &do_work_usleep;  break;
    case SLEEP_TYPE_YIELD:  tinfo.func = &do_work_yield;   break;
    case SLEEP_TYPE_PTHREAD_COND:  tinfo.func = &do_work_pthread_cond;   break;
    case SLEEP_TYPE_NANOSLEEP:  tinfo.func = &do_work_nanosleep;   break;
    default:
      printf("Invalid sleep type: %d\n", sleep_type);
      return -7;
  }

  // Initialize the thread creation attributes
  s = pthread_attr_init(&attr);
  if (s != 0) {
    printf("Error initializing thread attributes\n");
    return -2;
  }

  // Allocate the memory to track the threads
  threads = calloc(num_threads, sizeof(*threads));
  times = calloc(num_threads, sizeof(*times));
  if (threads == NULL) {
    printf("Error allocating memory to track threads\n");
    return -3;
  }

  // Initialize the number of samples
  num_samples = 0;
  // Perform the requested number of outer iterations
  for (inum=0; inum<outer_iterations; ++inum) {
    // Start all of the threads
    for (tnum=0; tnum<num_threads; ++tnum) {
      s = pthread_create(&threads[tnum], &attr, &do_test, &tinfo);

      if (s != 0) {
        printf("Error starting thread\n");
        return -4;
      }
    }

    // Wait for all the threads to finish
    for (tnum=0; tnum<num_threads; ++tnum) {
      s = pthread_join(threads[tnum], (void **)(&res));
      if (s != 0) {
        printf("Error waiting for thread\n");
        return -6;
      }

      // Save the result for processing when they're all done
      times[tnum] = res;
    }

    // For each of the threads
    for (tnum=0; tnum<num_threads; ++tnum) {
      // Increment the number of samples in the statistics
      ++num_samples;
      // Update the statistics with this measurement
      update_stats(&stats_clock, times[tnum]->clock, num_samples, tinfo.num_iterations, 1);
      update_stats(&stats_user, times[tnum]->user, num_samples, tinfo.num_iterations, clocks_to_usec);
      update_stats(&stats_sys, times[tnum]->sys, num_samples, tinfo.num_iterations, clocks_to_usec);
      // And clean it up
      free(times[tnum]);
    }
  }

  // Clean up the thread creation attributes
  s = pthread_attr_destroy(&attr);
  if (s != 0) {
    printf("Error cleaning up thread attributes\n");
    return -5;
  }

  // Finish the calculation of the standard deviation
  stats_clock.stddev = sqrtf(stats_clock.stddev / (num_samples - 1));
  stats_user.stddev = sqrtf(stats_user.stddev / (num_samples - 1));
  stats_sys.stddev = sqrtf(stats_sys.stddev / (num_samples - 1));

  // Print out the statistics of the times
  print_stats("gettimeofday_per_iteration", &stats_clock);
  print_stats("utime_per_iteration", &stats_user);
  print_stats("stime_per_iteration", &stats_sys);

  // Clean up the allocated threads and times
  free(threads);
  free(times);

  return 0;
}

Ich habe die Tests auf einem Dell Vostro 200 (Dual-Core-CPU) mit mehreren verschiedenen Betriebssystemversionen wiederholt. Mir ist klar, dass auf einige davon unterschiedliche Patches angewendet werden und es sich nicht um "reinen Kernelcode" handelt, aber dies war die einfachste Möglichkeit, die Tests auf verschiedenen Versionen des Kernels auszuführen und Vergleiche zu erhalten. Ich habe mit gnuplot Handlungen erstellt und die Version aus der Bugzilla zu diesem Problem hinzugefügt .

Alle diese Tests wurden mit dem folgenden Befehl mit dem folgenden Skript und diesem Befehl ausgeführt ./run_test 1000 10 1000 250 8 6 <os_name>.

#!/bin/bash

if [ $# -ne 7 ]; then
  echo "Usage: `basename $0` <sleep_time> <outer_iterations> <inner_iterations> <work_size> <max_num_threads> <max_sleep_type> <test_name>"
  echo "  max_num_threads: The highest value used for num_threads in the results"
  echo "  max_sleep_type: The highest value used for sleep_type in the results"
  echo "  test_name: The name of the directory where the results will be stored"
  exit -1
fi

sleep_time=$1
outer_iterations=$2
inner_iterations=$3
work_size=$4
max_num_threads=$5
max_sleep_type=$6
test_name=$7

# Make sure this results directory doesn't already exist
if [ -e $test_name ]; then
  echo "$test_name already exists";
  exit -1;
fi
# Create the directory to put the results in
mkdir $test_name
# Run through the requested number of SLEEP_TYPE values
for i in $(seq 0 $max_sleep_type)
do
  # Run through the requested number of threads
  for j in $(seq 1 $max_num_threads)
  do
    # Print which settings are about to be run
    echo "sleep_type: $i num_threads: $j"
    # Run the test and save it to the results file
    ./test_sleep $sleep_time $outer_iterations $inner_iterations $work_size $j $i >> "$test_name/results_$i.txt"
  done
done

Hier ist die Zusammenfassung dessen, was ich beobachtet habe. Ich werde sie diesmal paarweise vergleichen, weil ich denke, dass es auf diese Weise ein bisschen informativer ist.

CentOS 5.6 vs CentOS 6.2

Die Wanduhrzeit (gettimeofday) pro Iteration unter CentOS 5.6 ist variabler als 6.2. Dies ist jedoch sinnvoll, da das CFS die Prozesse besser mit der gleichen CPU-Zeit ausstatten sollte, was zu konsistenteren Ergebnissen führt. Es ist auch ziemlich klar, dass CentOS 6.2 in Bezug auf die Zeit, die es mit den verschiedenen Schlafmechanismen benötigt, genauer und konsistenter ist. Mittwoch CentOS 5.6 Mittwoch CentOS 6.2

Die "Strafe" ist definitiv in 6.2 mit einer geringen Anzahl von Threads (sichtbar auf Gettimeofday- und User Time-Plots) erkennbar, scheint sich jedoch mit einer höheren Anzahl von Threads zu verringern (der Unterschied in der User Time ist möglicherweise nur eine Abrechnungssache seit dem Benutzerzeitmessungen sind ja natürlich).

utime CentOS 5.6 utime CentOS 6.2

Das Zeitdiagramm des Systems zeigt, dass die Schlafmechanismen in 6.2 mehr System verbrauchen als in 5.6, was den vorherigen Ergebnissen des einfachen Tests von 50 Prozessen entspricht, bei denen nur Select aufgerufen wird und eine nicht triviale Menge an CPU in 6.2 verbraucht wird, jedoch nicht in 5.6 .

stime CentOS 5.6 stime CentOS 6.2

Ich halte es für erwähnenswert, dass die Verwendung von sched_yield () nicht die gleiche Strafe wie bei den Schlafmethoden verursacht. Meine Schlussfolgerung daraus ist, dass es nicht der Scheduler selbst ist, der das Problem verursacht, sondern die Interaktion der Schlafmethoden mit dem Scheduler, der das Problem darstellt.

Ubuntu 7.10 gegen Ubuntu 8.04-4

Der Unterschied in der Kernel-Version zwischen diesen beiden ist kleiner als der von CentOS 5.6 und 6.2, aber sie erstrecken sich immer noch über den Zeitraum, in dem CFS eingeführt wurde. Das erste interessante Ergebnis ist, dass select und poll die einzigen Schlafmechanismen zu sein scheinen, bei denen die "Strafe" für 8.04 gilt und diese Strafe weiterhin für eine höhere Anzahl von Threads gilt als mit CentOS 6.2.

Montag Ubuntu 7.10 Morgen Ubuntu 8.04-4

Die Benutzerzeit für select and poll und Ubuntu 7.10 ist unangemessen niedrig, daher scheint es sich um eine Art Buchhaltungsproblem zu handeln, das damals bestand, aber ich glaube, dass es für das aktuelle Problem / die aktuelle Diskussion nicht relevant ist.

utime Ubuntu 7.10 utime Ubuntu 8.04-4

Die Systemzeit scheint unter Ubuntu 8.04 höher zu sein als unter Ubuntu 7.10, aber dieser Unterschied ist weit weniger ausgeprägt als bei CentOS 5.6 gegenüber 6.2.

stime Ubuntu 7.10 stime Ubuntu 8.04-4

Hinweise zu Ubuntu 11.10 und Ubuntu 12.04

Das Erste, was hier zu beachten ist, ist, dass die Diagramme für Ubuntu 12.04 mit denen ab 11.10 vergleichbar waren, so dass sie keine unnötige Redundanz verhindern.

Insgesamt zeigen die Diagramme für Ubuntu 11.10 den gleichen Trend wie bei CentOS 6.2 (was darauf hinweist, dass es sich um ein Kernel-Problem im Allgemeinen und nicht nur um ein RHEL-Problem handelt). Die einzige Ausnahme ist, dass die Systemzeit unter Ubuntu 11.10 etwas höher zu sein scheint als unter CentOS 6.2, aber auch hier ist die Auflösung bei dieser Messung sehr natürlich, und ich denke, dass jede andere Schlussfolgerung als "es scheint etwas höher zu sein "würde auf dünnes Eis treten.

Ubuntu 11.10 vs Ubuntu 11.10 mit BFS

Eine PPA, die BFS mit dem Ubuntu-Kernel verwendet, finden Sie unter https://launchpad.net/~chogydan/+archive/ppa. Diese wurde installiert, um diesen Vergleich zu erstellen . Ich konnte keinen einfachen Weg finden, CentOS 6.2 mit BFS auszuführen, also habe ich diesen Vergleich durchgeführt. Da die Ergebnisse von Ubuntu 11.10 so gut mit CentOS 6.2 vergleichbar sind, halte ich dies für einen fairen und aussagekräftigen Vergleich.

Montag Ubuntu 11.10 Gettimeofday Ubuntu 11.10 mit BFS

Der wichtigste Punkt ist, dass mit BFS nur Select und Nanosleep die "Strafe" bei einer geringen Anzahl von Threads induziert wird, aber dass es eine ähnliche "Strafe" (wenn nicht eine größere) zu induzieren scheint, wie bei CFS für eine höhere Anzahl der Themen.

utime Ubuntu 11.10 utime Ubuntu 11.10 mit BFS

Der andere interessante Punkt ist, dass die Systemzeit bei BFS kürzer zu sein scheint als bei CFS. Wieder beginnt dies aufgrund der Grobheit der Daten auf dünnem Eis zu laufen, aber es scheint ein gewisser Unterschied zu bestehen, und dieses Ergebnis stimmt mit dem einfachen 50-Prozess-Select-Loop-Test überein, der mit BFS eine geringere CPU-Auslastung aufwies als mit CFS .

stime Ubuntu 11.10 stime Ubuntu 11.10 mit BFS

Die Schlussfolgerung, die ich aus diesen beiden Punkten ziehe, ist, dass BFS das Problem nicht löst, aber zumindest seine Auswirkungen in einigen Bereichen zu verringern scheint.

Fazit

Wie bereits erwähnt, glaube ich nicht, dass dies ein Problem mit dem Scheduler selbst ist, sondern mit der Interaktion zwischen den Schlafmechanismen und dem Scheduler. Ich betrachte diese erhöhte CPU-Auslastung in Prozessen, die im Ruhezustand arbeiten und wenig bis gar keine CPU benötigen, als Regression von CentOS 5.6 und als große Hürde für jedes Programm, das eine Ereignisschleife oder einen Abfragemechanismus verwenden möchte.

Gibt es irgendwelche anderen Daten oder Tests, die ich ausführen kann, um das Problem weiter zu diagnostizieren?

Aktualisierung am 29. Juni 2012

Ich habe das Testprogramm ein wenig vereinfacht und kann hier gefunden werden (Der Pfosten begann, die Längenbeschränkung zu überschreiten, also musste er verschoben werden).


3
Wow, gründliche Analyse - aber mit so vielen Daten wird die ursprüngliche Frage für mich immer unübersichtlicher. Können Sie es auf den Punkt bringen 1) einen einzelnen Test 2) eine einzelne Distribution 3) zwei verschiedene Kernel 4) die 15% ige Verlangsamung? Wenn Ihre Hypothese im letzten Absatz richtig ist, ist es an der Zeit, unterschiedliche Kernelquellen zu verwenden, aber es scheint, dass die anderen Variablen zuerst entfernt werden sollten.
ckhan

Ich habe einige Ausgaben aus der Testanwendung hinzugefügt und jetzt den Vergleich paarweise durchgeführt, um zu versuchen, es ein wenig einfacher zu machen, alle Informationen zu verdauen.
Dave Johansen

Ich habe versucht, einen Blick auf diese Bugzilla zu werfen, aber Redhat sagt, dass es sich um eine "interne Bugzilla" handelt, die für die Öffentlichkeit nicht sichtbar ist. Gab es Updates dazu?

Ich bin neu in der ganzen RedHat-Bugsache, das war also vielleicht etwas, was ich getan (oder nicht getan) habe, als ich den Bug erstellt habe, der das getan hat, aber das einzige Update, das ich bisher gehört habe, ist ein Update für a Parameter, der das Verhalten bei Prozessoren mit Hyperthreading verbessert, aber noch keine echte Korrektur.
Dave Johansen

2
CFS ist der vollkommen faire Scheduler? Das hört sich interessant an - ich bin auch mit einer Java-basierten Anwendung auf SLES11 SP2 auf ein Leistungsproblem gestoßen. Der Unterschied (zu SP1) ist die Änderung in CFS ...
Nils

Antworten:


1

Laut den Release-Notes zu SLES 11 SP2 könnte dies eine Änderung der Art und Weise sein, in der CFS implementiert wird.

Da SLES 11 SP2 die aktuelle SLES-Version ist, ist dieses Verhalten immer noch gültig (wie es für alle 3.x-Kernel scheint).

Diese Änderung war beabsichtigt - könnte aber "schlimme" Nebenwirkungen haben. Vielleicht hilft Ihnen eine der beschriebenen Problemumgehungen ...


Anscheinend stimmt etwas mit dem Link nicht und der richtige ist hier , aber ich werde diese Problemumgehungen ausprobieren und prüfen, ob sie die Leistung verbessern.
Dave Johansen

Weitere Neuigkeiten dazu?
Vonbrand

@vonbrand Sie müssen wahrscheinlich Dave fragen ...
Nils
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.