Вопросы Теги

отбрасывания rsyslog обмениваются сообщениями чрезмерно

Если Вы хотели бы ключ, они раньше подписывали RPMs с, я скопировал его ниже. Я получил его от этой регистрации форумов Fedora и также использования wayback на http://gd.tuwien.ac.at/infosys/phone/skype/rpm-public-key.asc, который я видел, упомянул несколько мест.

Ключ отдельно бесполезен, если скайп на самом деле не подписывает их RPMs, который действительно имеет место. Проверка gpg жалуется, потому что об/мин не подписывается, не потому что у Вас нет ключа.

Если Вы работаете rpm -K some.rpm можно проверить, чтобы видеть, подписывается ли об/мин. Заметьте в выводе в команде ниже, об/мин в скайпе делает не перечисляет 'gpg' нигде, тогда как со знаком 'на уровне' об/мин от CentOS делает и 'aspell' со знаком из Научного Linux делает. Можно работать rpm -Kv some.rpm если Вы хотите больше подробного вывода. Веб-сайт об/мин имеет больше информации о подписании RPMs и как сказать, подписываются ли они, если Вам интересно.

$ rpm -K skype-2.1.0.81-fc.i586.rpm
skype-2.1.0.81-fc.i586.rpm: sha1 md5 OK
$

# This is a CentOS RPM that I have already imported the key for.
$ rpm -K at-3.1.10-43.el6.i686.rpm
at-3.1.10-43.el6.i686.rpm: rsa sha1 (md5) pgp md5 OK
$

# This is a Scientific Linux RPM that I do not have a key for.
# It complains I don't have it but still shows the RPM as being signed.
$ rpm -K aspell-0.60.6-12.el6.i686.rpm 
aspell-0.60.6-12.el6.i686.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#192a7d7d) 
$

Таким образом, проблема, которую Вы имеете, не состоит в том, что Вы не можете получить их ключ GPG, случается так, что они не подписывают свой RPMs. Вы оказываетесь перед необходимостью обходиться без помощи gpgcheck для устанавливания скайпа.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEFQUsMRBACW4yLV31T5eT/7k35BjLeCrxy+pkudrOIGVPmszqjCO8KBHco3
islbMJT7WspxAmJd3npQ2uKYyicXemEzhQOBxmS1y8obtaoTy7HmqbaLDroOYldf
YJcsEzvqb+xB4zyP4Mpw1ySHzcURcxsQFTwu33TywL8ot6HmpNGetqx1cwCg32aR
o3RE6geDfwGaZDO9R1vf0SkD/32sZMEX7y3c0f2d7Oc2GOoLl4g4nE6ljPmuo0xB
n0LVSjKH0nnG9NblBtR684D1wqaWvA050zcLWgnjjiRcdEaoEvrVzinwp49Zm12Q
KXpqnhgP2WxTpaOAWIl+ADT+SihG0w6jICFt0wkj+QCnYtFzQa0DL2KJ41h7ij9V
Cd2SBACUPTp3A20JjTugc8fL6TOPOjHoN8aCZUCBNpPRiTj1CHyngStEEgvD7s9f
WEejkWPFvpKPvAlTAhGKEjLZB5gPr3XTDnVwo1O87Q0jR/JsNb8ogInDh+AgQR8X
Y67EXBKRnbjIGl5OgE0fIbQwU7pcYrB9CCpLMDEqlmlDiGT8H7QoU2t5cGUgVGVj
aG5vbG9naWVzIFMuQS4gPGluZm9Ac2t5cGUubmV0PoheBBMRAgAeBQJBUFLDAhsD
BgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEAJ1r4LWa3Ru95kAoLYbi9b8jNjAEQbV
cmGkwTBzBy2fAJ4l4NNN1oJg/Z3aVNAZgt/DYoiB9bkBDQRBUFLHEAQAw9V3v2eX
C40BSGF6IEBqxPcGtPZflZAtpxjxMDlhBqL1QWctGW/5eezj/pF7vCunxzXoBUGG
noE/R4hslYsbtp8cVbpu5ri1/DrtFrZzcNzBkxR3lJ8d+PUrdV9bkRUjo8pcL+ZJ
2g3assDBaHvVval5Bw5RKgjEed/kOL18cFcAAwUD/2AylYyHG+zEqqeN1o3vjtv+
IW3qbWn3DhojKgnpOjXiX4cDExXc5BDvOo6Xq6a0OM4Ga1KCbOrd+7tfYrKd1OCK
IiuW8ptG8khJAS3LL0Fx3okr7/VbmGtRRFvFCfxkYKzm/mAe5uzSco+Ym1JNPZtH
W9oAPDERDLRB/0TlKpYSiEkEGBECAAkFAkFQUscCGwwACgkQAnWvgtZrdG6ojgCg
1vsm73qch3XrZzwhgdn1O7Y6O8AAnjX9Vg31wBpIrqid/IMhyA43RC5m
=Up0v
-----END PGP PUBLIC KEY BLOCK-----

5
30.04.2013, 10:45
2 ответа

Обновление новейшей версии rsyslog. У нас была эта точная проблема на работе, и это - единственная вещь, которая решила ее. Более ранняя версия (версии) имела проблемы с определением имен, и даже выключение его не решило его. 7.x ответвление решает проблему. Я буду видеть, могу ли я найти определенную ссылку.

6
27.01.2020, 20:37
  • 1
    я нашел некоторые свои старые электронные письма. Вот определенное объяснение относительно того, почему оно отбрасывает пакеты - kb.monitorware.com / …. Проблема с обратным определением имен, и в какой-то момент флаг "-x" был представлен для выключения определения имен. В версии 7 ошибка исправлена так, можно сохранить определение имен И получить пакеты - blog.gerhards.net/2011/06/full-blown-dns-cache-for-rsyslog.html. Последнее сообщение из блога автора rsyslog. –  Greg Cain 29.04.2013, 19:20
  • 2
    я не могу полагать, что Redhat не бэкпортировал ту фиксацию. Они обычно делают. Номер версии не говорит, сколько мер бэкпорт включено. –  Nils 30.04.2013, 09:56

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

rx_no_buffer_count: 103 кажется, базовая проблема здесь.

Это говорит, что было 103 пакета TCP, которые были отброшены, ПРЕЖДЕ ЧЕМ они могли быть переданы операционной системе.

Отбрасывание было зарегистрировано в NIC (и не передано ОС, таким образом, netstat не показал это). Для решения проблемы, необходимо будет propably увеличить receive-ring-buffer размер в настройках NIC.

Сделайте a ethtool -g eth0 видеть Ваши текущие и возможные настройки для RX.

На основе моего опыта, устанавливающего кольцевой буфер RX на 2048 или 3172, довольно хорошо.

Это даст время NIC для буферизации входящих пакетов TCP, пока аппаратные средства (этому нужен PCI-interrrupt) и ОС не будут иметь время для обработки пакетов.

Вот explantion от Redhat, что продолжается здесь.

Для внесения этого изменения персистентным изменитесь, ETHTOOL_OPS нравится описанный здесь.

1
27.01.2020, 20:37
  • 1
    Привет Ноли, спасибо за указание на отбрасывания TCP... честно, то число является настолько крошечным по сравнению с количеством сообщений системного журнала, которые мы отбрасывали, я не так уверен, что это находится в критическом пути решения главного фокуса вопроса. Я посмотрю на настройку буферов NIC через –  Mike Pennington 30.04.2013, 10:57
  • 2
    @MikePennington Просто мое предположение. Я обновил свой ответ с двумя ссылками для дополнительных материалов для чтения. Спросите сетевых парней о статистической величине ошибки порта для порта, где Ваш сервер присоединяется, также (и обновите свой вопрос с результатами). –  Nils 30.04.2013, 12:16

Теги

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