Форум КриптоПро
»
Средства криптографической защиты информации
»
Встраивание
»
Очень медленная работа под Linux функции «CertGetCertificateChain»
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.07.2014(UTC) Сообщений: 97  Откуда: Москва Сказал(а) «Спасибо»: 21 раз
|
Здравствуйте. Тестовая утилита под Windows и Linux: https://disk.yandex.ru/d/Dsl_jmEY-E3wMQХранилище промежуточных АУЦ под Linux: https://disk.yandex.ru/d/VpcBO3UFLa0AYQУдивительная вещь – если в хранилище промежуточных АУЦ много сертификатов, то функция «CertGetCertificateChain» работает под Linux существенно медленнее (100 – 1000 раз), чем под Windows. На нашем тестовом сервере Linux (достаточно мощном) скорость проверки 4 сертификата в секунду или медленнее, причем, независимо от количества нитей запускаемых в тестовой утилите. Под сервером Windows (с аналогичной мощностью) все гораздо быстрее. Под Windows запускаем тестовую утилиту с параметрами 8 1024 2 (8 нитей, 1024 проверок сертификатов в каждой нити, в вызове функции флаги «CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT | CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY»). Все отрабатывает за 60 секунд (плюс / минус). Под Linux запускаем тестовую утилиту с параметрами 1 1024 2 (1 нить, 1024 проверок сертификатов в каждой нити, в вызове функции флаги «CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT | CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY»). Все отрабатывает за 265 секунд (плюс / минус). Если запустить утилиту с параметрами 2 512 2 – то она отрабатывает за 369 секунд (две нити, но тот же суммарный объем проверок). Если тестовую утилиту запустить под пользователем, у которого хранилище промежуточных АУЦ практически пустое, то она отработает очень быстро (5 секунд). Складывается впечатление, что хранилище промежуточных АУЦ является неким неразделяемым, критичным ресурсом под Linux-ом, который существенно замедляет построение цепочки доверия для сертификата. Понимаете, у нас проект по «импортозамещению» и в рамках этого проекта надо отказаться от Windows. Но под Linux-ом выясняется вот такое вот «замедление». Хотелось бы получить ваши комментарии. Может мы что-то не так делаем? Параметры серверов: Windows: 8CPU (Intel Xeon E312 – 2.59GHz) / 32Gb-Ram / 50Gb-HDD / Windows Server 12 / КриптоПРО 4.0.9842 Linux: 8CPU (Intel Xeon E312 – 2.59GHz) / 32Gb-Ram / 50Gb-HDD / Astra Linux 1.6 / КриптоПРО v5.0.10009 KC2 Release Ver:5.0.12222 Похожий вопрос уже поднимался пять лет назад: https://www.cryptopro.ru...aspx?g=posts&t=11625С тех пор подвижек нет? С уважением, Константин Ткачук.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,271
Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 446 раз в 325 постах
|
Здравствуйте. Мы постоянно занимаемся узкими местами в производительности. Ваш пример с демонстрацией проблемы выше всяких похвал. Пожалуйста, пишите о проблемах чаще, можно в личку. В релизе КриптоПро CSP 5.0 R3 (сборка 5.0.12330 Nemesis) мы добавили кэширование ChainEngine по умолчанию (запрос для ориентира в changelog CPCSP-12068). С параметрами 8 1024 2 ваш пример на Core i3-7100 отрабатывает за 3914 milliseconds. Тем не менее к сертифицированному релизу КриптоПро CSP 5.0 R2 (сборка 5.0.12000 Kraken) мы внесли значительные оптимизации в проверку цепочек в близком к вашему сценарии (см. CPCSP-12064 в changelog). И если немного модифицировать ваш пример, то можно получить 4596 milliseconds. Для этого надо заранее создать ChainEngine и передать ему уже открытые хранилища Root и Ca. Исправленный пример приложил.  test.cpp.zip (3kb) загружен 12 раз(а).P.S. На Linux рекомендую пользоваться valgrind-ом: он отлично помогает находить ошибки в коде. У вас была такая (тоже исправлена): Код:
root@mini-docker-11:/tmp/chainperf/Linux# valgrind ./testLinux 1 2 2 ../=testData2/1.cer ../=testData2/2.cer
==7703== Memcheck, a memory error detector
==7703== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7703== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==7703== Command: ./testLinux 1 2 2 ../=testData2/1.cer ../=testData2/2.cer
==7703==
Params - thread count: 1, loop count: 2, check revocation 2
Load file: ../=testData2/1.cer (size: 2093)
Load file: ../=testData2/2.cer (size: 1305)
=== Start
==7703== Mismatched free() / delete / delete []
==7703== at 0x4C2D2DB: operator delete(void*) (vg_replace_malloc.c:576)
==7703== by 0x109ABB: main (in /tmp/chainperf/Linux/testLinux)
==7703== Address 0x6df2190 is 0 bytes inside a block of size 8 alloc'd
==7703== at 0x4C2C93F: operator new[](unsigned long) (vg_replace_malloc.c:423)
==7703== by 0x10997E: main (in /tmp/chainperf/Linux/testLinux)
==7703==
=== Finish: 2927 milliseconds elapsed
==7703==
==7703== HEAP SUMMARY:
==7703== in use at exit: 379,298 bytes in 339 blocks
==7703== total heap usage: 85,058 allocs, 84,719 frees, 742,584,066 bytes allocated
==7703==
==7703== For a detailed leak analysis, rerun with: --leak-check=full
==7703==
==7703== For counts of detected and suppressed errors, rerun with: -v
==7703== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Отредактировано пользователем 29 ноября 2021 г. 13:52:15(UTC)
| Причина: Релиз вышел, добавил ссылку. |
|
 2 пользователей поблагодарили Русев Андрей за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.07.2014(UTC) Сообщений: 97 Откуда: Москва Сказал(а) «Спасибо»: 21 раз
|
Спасибо, за Ваш ответ.
Вопрос: в Вашем варианте с "hChainEngine" - увидит ли объект, кеширующий хранилища сертификатов, изменения в списке промежуточных / корневых сертификатов и СОС. Нужно ли будет пересоздавать "hChainEngine" при изменении содержимого хранилищ?
Просто в нашем ПО есть отдельная нить, которая периодически обновляет список промежуточных АУЦ, занимается скачиванием СОС-ов для АУЦ и установкой их в хранилище. А проверкой сертификатов (построением цепочки доверия к ним) занимаются рабочие нити - поэтому и возникают вопросы с обновлением информации в "hChainEngine".
Плюс еще вопрос - судя по Вашему примеру "hChainEngine" не является потоко-безопасным и его надо создавать для каждой рабочей нити свой?
С уважением, Константин Ткачук.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,271
Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 446 раз в 325 постах
|
Отличные вопросы! Действительно, мой пример не увидит изменений в ca/root. Чтобы это починить, после открытия хранилища можно задать ему Код:CertControlStore(hStore, 0, CERT_STORE_CTRL_AUTO_RESYNC, NULL)
Реализация чувствительна к файловой системе, на которой лежит хранилище: на fat/exfat/hfs и прочей дичи изменения могут оставаться незамеченными некоторое время, но в любом случае через 3 секунды перечитывание хранилища с диска произойдёт. Если такая паразитная нагрузка вас не устраивает, можно либо вручную делать CERT_STORE_CTRL_RESYNC, либо управлять этой задержкой (в 3 секунды) через конфиг. Но раз у вас отдельная нить, обновляющая хранилище, то пусть она в самом начале его откроет, больше не закрывает и передаст хэндл рабочим нитям (при инициализации структуры CERT_CHAIN_ENGINE_CONFIG). Потокобезопасность должна быть, но исправления относительно свежие, так что всякое бывает. Известная проблема в сертифицированной сборке CSP 5.0.12000 Kraken: CertCreateCertificateChainEngine не дублирует хэндлы передаваемых хранилищ, поэтому нельзя сделать CertOpenStore + CertCreateCertificateChainEngine + CertCloseStore - надо закрывать хранилище в самом конце работы. В новых сборках это исправлено. |
|
2 пользователей поблагодарили Русев Андрей за этот пост.
|
idtks оставлено 26.11.2021(UTC), Андрей * оставлено 26.11.2021(UTC)
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.07.2014(UTC) Сообщений: 97 Откуда: Москва Сказал(а) «Спасибо»: 21 раз
|
Попробовал перенести Ваши подсказки в код продакшена - почти все получилось, кроме флага "CERT_STORE_CTRL_AUTO_RESYNC". Без этого флага, сервер выдает где-то 400 проверок сертификатов в секунду и все работает ровно (без долгих проверок сертификатов). А вот стоит добавить установку этого флага (как Вы писали в последнем сообщении) и сервер начинает работать очень странно: резко вырастает нагрузка на CPU, появляются сертификаты проверка которых занимает более 10 секунд (при чем при каждом прогоне теста разные) - в общем "пулемет не стреляет". Буду смотреть дальше и лепить костыли, чтобы заменить флаг "CERT_STORE_CTRL_AUTO_RESYNC". С уважением, Константин Ткачук. Отредактировано пользователем 26 ноября 2021 г. 16:50:50(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,271
Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 446 раз в 325 постах
|
Если есть возможность переписать на передачу хэндла прям из той нити, которая обновляет хранилище, будет в любом случае лучше. Но топорно можете попробовать покрутить "время перечитывания в любом случае", уменьшив его с 3 секунд, скажем, до 300 мс: Код:/opt/cprocsp/sbin/amd64/cpconfig -ini '\config\Capilite' -add long worst_store_resync_period 300
Имейте в виду, что значение 2000000000 является особым и отключает оптимизацию. Отредактировано пользователем 29 ноября 2021 г. 11:06:37(UTC)
| Причина: Не указана |
|
1 пользователь поблагодарил Русев Андрей за этот пост.
|
idtks оставлено 27.11.2021(UTC)
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,271
Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 446 раз в 325 постах
|
Поправил предыдущий комментариий. Поясню. Пока текущее время будет отличаться от времени последнего изменения файла с хранилищем меньше, чем на worst_store_resync_period, хранилище будет считываться с диска при каждом перечислении сертификатов или CRL. Именно в этот интервал вы наблюдали проверки по 10 секунд. Уменьшать эту величину нужно с осторожностью (в случае экзотических ФС и настроек монтирования, как я писал выше), но есть рецепт успеха: если записывать в хранилище за ОДНУ операцию (CertOpenStore, CertAddCRLContextToStore,..., CertAddCRLContextToStore, CertCloseStore) (запись происходит на CertCloseStore) и делать это существенно реже, чем разрешение меток времени файловой системы (не чаще раза в секунду, грубо говоря)
то worst_store_resync_period можно опускать до минимальных значений (1 мс)Отредактировано пользователем 29 ноября 2021 г. 11:26:09(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.07.2014(UTC) Сообщений: 97 Откуда: Москва Сказал(а) «Спасибо»: 21 раз
|
Здравствуйте. Небольшой вопрос - по сообщениям CSP в системном логе Linux - "/var/log/syslog": при нагрузочном тестировании обнаружили, что этот файл заполнен сообщениями вот такого вида: Цитата:Dec 7 14:36:43 tks-VB-LinuxMint mod_scc_crypto (Apache)[6106]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:36:43 tks-VB-LinuxMint mod_scc_crypto (Apache)[6106]: <capi10>CryptVerifySignatureW!failed: LastError = 0x80090006
Dec 7 14:36:43 tks-VB-LinuxMint mod_scc_crypto (Apache)[6106]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:36:43 tks-VB-LinuxMint mod_scc_crypto (Apache)[6106]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004
Dec 7 14:36:54 tks-VB-LinuxMint mod_scc_crypto message repeated 109 times: [ (Apache)[6106]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004]
Dec 7 14:36:55 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004
Dec 7 14:36:59 tks-VB-LinuxMint mod_scc_crypto message repeated 32 times: [ (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004]
Dec 7 14:37:00 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi10>CryptVerifySignatureW!failed: LastError = 0x80090006
Dec 7 14:37:00 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:37:00 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004
Dec 7 14:37:06 tks-VB-LinuxMint mod_scc_crypto message repeated 15 times: [ (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004]
Dec 7 14:37:06 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi10>CryptVerifySignatureW!failed: LastError = 0x80090006
Dec 7 14:37:06 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:37:06 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004
Dec 7 14:37:12 tks-VB-LinuxMint mod_scc_crypto message repeated 20 times: [ (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004]
Dec 7 14:37:12 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi10>CryptVerifySignatureW!failed: LastError = 0x80090006
Dec 7 14:37:12 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:37:12 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi10>CryptVerifySignatureW!failed: LastError = 0x80090006
Dec 7 14:37:12 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptVerifyCertificateSignature!failed: LastError = 0x80090006
Dec 7 14:37:14 tks-VB-LinuxMint mod_scc_crypto (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004
Dec 7 14:37:20 tks-VB-LinuxMint mod_scc_crypto message repeated 68 times: [ (Apache)[6104]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004]
Dec 7 14:37:20 tks-VB-LinuxMint mod_scc_crypto (Apache)[6106]: <capi20>CryptRetrieveObjectByUrlA!Object not found, error code : 80092004 Можно ли как-то их "убрать", причем, не запрещая полностью логироание в "/var/log/syslog"? Есть подозрение, что через несколько дней системный лог переполняется и из-за этого сильно деградирует скорость проверки сертификатов, поэтому приходится перезагружать ОС, чтобы восстановить быстродействие. С уважением, Константин Ткачук.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 16.04.2008(UTC)
Сообщений: 1,271
Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 446 раз в 325 постах
|
Мы провели значительную работу по устранению лишних диагностических сообщений в журнале в новых версиях. Для старых можно отключить журналирование назойливх модулей, задав соответствующую (например, нулевую) маску. Подробней о маске написано в /etc/opt/cprocsp/config64.ini. Настоятельно рекомендуется НЕ редактировать это файл руками, а пользоваться API: Код:/opt/cprocsp/sbin/amd64/cpconfig -loglevel capi10 -mask 0
/opt/cprocsp/sbin/amd64/cpconfig -loglevel capi20 -mask 0
Добавлю, что тормоза, появляющиеся при росте журнала - это ошибка системы журналирования в systemd. При классический системе журналирования таких проблем нет. |
|
1 пользователь поблагодарил Русев Андрей за этот пост.
|
idtks оставлено 10.12.2021(UTC)
|
|
|
Форум КриптоПро
»
Средства криптографической защиты информации
»
Встраивание
»
Очень медленная работа под Linux функции «CertGetCertificateChain»
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
