Как проверить, что вызывает производительность проблема

[Edit] Этот вопрос отличается от того, что предлагает модератор, я пытаюсь выяснить, что могло привести к замедлению работы API из-за нескольких строк кода. Я не пытаюсь планировать мощность, как это предлагает модератор.

Я унаследовал сервер с некоторыми проблемами производительности. На нем работает node js, nginx, базовый стек MEAN. (Хотя БД на другом сервере)

Каждый раз, когда я копировал файл (файл журнала размером около 150 МБ) или создавал файл с таким размером, вывод «iostat -x 1» был таким, как показано ниже

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda               0.00  8137.62    0.00   49.50     0.00 29924.75   604.48    17.32  123.54  16.50  81.68

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.59    0.00   24.34    0.00    0.00   74.07

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda               0.00     0.00    0.00   39.39     0.00 36606.06   929.23     2.42  351.64   1.87   7.37

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.78    0.00   24.44    0.00    0.00   72.78

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

Причина, по которой я говорю об этом, заключается в том, что иногда простой RESTFUL API, который обслуживает мой nodejs, будет медленно реагировать (от 10 мс до 500 мс), и я не уверен, что искать или проверять, что вызывает это.

Та же самая кодовая база скопирована на другой сервер будет работать без проблем, упомянутая выше проблема - единственное, что я могу обнаружить, что с сервером может быть что-то не так, но я не уверен, что это такое.

Коды выглядят следующим образом:

В одном файле statistic / index.js:

var tracker = function (data) {
  piwik.tracker(data);
};

exports.tracker = tracker;

В другом файле statistic / piwik.js:

exports.tracker = function (data) {
  var params = {};

  /** Assign params with data - just static string **/

  /** API_URL is another machine in same LAN **/
  needle.post(API_URL, params, function (err, response, body) {
    if (err || (response.statusCode !== 200 && response.statusCode !== 204)) {
      util.error(err);
    }
  });
};

В файле, который вызывает указанный выше маршрут / getuser.js:

exports.getUser = function (req, res) {

  async.auto({
    get_user: function (cb) {
      /** Read user data from DB **/
      cb();
    },
    record_statistic: ['get_user', function (cb) {
      statistic.tracker({ /** Pass static string data **/});
      cb();
    }]
  }, function (err) {
    if (err) {
      res.json(err);
    } else {
      res.json();
    }
  });
};

Причина, по которой я упоминаю приведенные выше коды, заключается в том, что, когда я отметил statistic.tracker ({/ ** Передать статические строковые данные ** /} ); Функция будет отвечать в течение 50 мс, но если я включу ее большую часть времени, она будет отвечать в пределах от 100 до 500 мс. Я даже поставил проверку отметки времени для "игольчатого" HTTP-сообщения, и он отвечает в течение 10-20 мсек.

Когда я копирую файл (cp -p x.txt y.txt), особенно если это файл размером> 100 МБ, это также замедляет работу моего узла js. Но даже когда я ничего не делаю на сервере, кроме прослушивания запросов nginx и node js, приведенные ниже коды будут медленно реагировать. (Если я не заметил код)

Я подозреваю ввод-вывод, но где еще проверить? или на что обращать внимание?

Ниже приведены некоторые сведения о сервере:

[ec2-user@tlp-backend logs]$ uname -a
Linux tlp-backend 2.6.32-71.el6.x86_64 #1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux

[ec2-user@tlp-backend logs]$ cat /proc/scsi/scsi 
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: NECVMWar Model: VMware IDE CDR10 Rev: 1.00
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor: VMware,  Model: VMware Virtual S Rev: 1.0 
  Type:   Direct-Access                    ANSI  SCSI revision: 02

[ec2-user@tlp-backend logs]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30502
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[ec2-user@tlp-backend logs]$ more /proc/meminfo 
MemTotal:        3918960 kB
MemFree:          392260 kB
Buffers:          296116 kB
Cached:          1205652 kB
SwapCached:          364 kB
Active:          1725084 kB
Inactive:        1155564 kB
Active(anon):     949492 kB
Inactive(anon):   430528 kB
Active(file):     775592 kB
Inactive(file):   725036 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4095992 kB
SwapFree:        4092872 kB
Dirty:                28 kB
Writeback:             0 kB
AnonPages:       1378528 kB
Mapped:            29860 kB
Shmem:              1140 kB
Slab:             588628 kB
SReclaimable:     461108 kB
SUnreclaim:       127520 kB
KernelStack:        2296 kB
PageTables:        16940 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6055472 kB
Committed_AS:    1829320 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      288456 kB
VmallocChunk:   34359446140 kB
HardwareCorrupted:     0 kB
AnonHugePages:    507904 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10240 kB
DirectMap2M:     4184064 kB

[ec2-user@tlp-backend logs]$ more /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 44
model name  : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
stepping    : 2
cpu MHz     : 2400.000
cache size  : 12288 KB
physical id : 0
siblings    : 2
core id     : 0
cpu cores   : 2
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 11
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch
_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_
spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lah
f_lm ida arat
bogomips    : 4800.00
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model       : 44
model name  : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
stepping    : 2
cpu MHz     : 2400.000
cache size  : 12288 KB
physical id : 0
siblings    : 2
core id     : 1
cpu cores   : 2
apicid      : 1
initial apicid  : 1
fpu     : yes
fpu_exception   : yes
cpuid level : 11
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch
_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_
spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lah
f_lm ida arat
bogomips    : 4800.00
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model       : 44
model name  : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
stepping    : 2
cpu MHz     : 2400.000
cache size  : 12288 KB
physical id : 1
siblings    : 2
core id     : 0
cpu cores   : 2
apicid      : 2
initial apicid  : 2
fpu     : yes
fpu_exception   : yes
cpuid level : 11
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch
_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_
spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lah
f_lm ida arat
bogomips    : 4800.00
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model       : 44
model name  : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
stepping    : 2
cpu MHz     : 2400.000
cache size  : 12288 KB
physical id : 1
siblings    : 2
core id     : 1
cpu cores   : 2
apicid      : 3
initial apicid  : 3
fpu     : yes
fpu_exception   : yes
cpuid level : 11
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat 
pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch
_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc aperfmperf unfair_
spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lah
f_lm ida arat
bogomips    : 4800.00
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

 top - 18:02:58 up 26 days, 18:49,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 176 total,   1 running, 175 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.1%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3918960k total,  3522368k used,   396592k free,   295340k buffers
Swap:  4095992k total,     3120k used,  4092872k free,  1201660k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
    1 root      20   0 19340 1248 1040 S  0.0  0.0   0:03.45 init               
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.01 kthreadd           
    3 root      RT   0     0    0    0 S  0.0  0.0   0:02.55 migration/0        
    4 root      20   0     0    0    0 S  0.0  0.0   0:01.57 ksoftirqd/0        
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0         
    6 root      RT   0     0    0    0 S  0.0  0.0   0:18.87 migration/1        
    7 root      20   0     0    0    0 S  0.0  0.0   0:01.34 ksoftirqd/1        
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1         
    9 root      RT   0     0    0    0 S  0.0  0.0   0:01.90 migration/2        
   10 root      20   0     0    0    0 S  0.0  0.0   0:01.30 ksoftirqd/2        
   11 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2  
1
задан 11 November 2015 в 04:19
1 ответ

Судя по всему, основная проблема исходит из самого кода.Когда вы смешиваете async.auto с пакетом иглы, вам необходимо явно указать {connection: 'keep-alive'} в заголовке HTTP

Подробнее см. Здесь: https://github.com/tomas/needle / issues / 148

0
ответ дан 4 December 2019 в 06:53

Теги

Похожие вопросы