Многопоточность, Linux, SQLite, NTFS
Борьба была беспощадная, но результат радует.
Итак, в сухом остатке - для грамматического движка сделан и выполнен многопоточный нагрузочный тест. Это когда несколько (от 3х до 11) потоков одновременно вызывают sol_MorphologyAnalysis и sol_SyntaxAnalysis для одного экземпляра загруженного словаря, и сравнивают результаты для примерно 6000 эталонных английских предложений.
Раньше такой тест у меня был только для MS Windows варианта движка (32 и 64 битные dll). Он отлично выявляет всю грязь в коде с точки зрения доступа из множества потоков. Особенно это касается кэшей для данных в SQL хранилище. Когда десять потоков запрашивают какой-либо кэш в режиме читателя, а один поток, не найдя нужные данные, хочет стать писателем и подгрузить что-то из БД, любая ерунда с синхронизацией очень быстро разрушает кучу и валит систему.
Под Linux тест использует "голые" pthread_xxx, я решил обойтись без ООП-оберток, чтобы не тащить в тесты дополнительные внешние зависимости. В целом все просто, принципиалтьных отличий от win-specific функций
В целом, под Linux нашлось несколько ошибок. В частности, пришлось переработать использование мьютексов, перевести часть в рекурсивный режим. Ну и самое главное - чтобы открытое соединение с SQLite базой нормально обслуживало множество параллельных потоков, пришлось и под Linux открывать БД с помощью sqlite3_open_v2 с флагом SQLITE_OPEN_FULLMUTEX.
Не обошлось и без некоторого шаманизма. Древняя версия libsqlite3 под моим линуксом отказалась выполнять sqlite3_open_v2, и я решил обновиться до текущей версии 3.7.11. Под Win либа скомпилировалась и заработала без каких-либо проблем. А под Linux неожиданно всплыла ошибка там, где я никак ее не ожидал.
При сборке словаря на одном из этапов, при выгрузке данных в sqlite-базу, попытка зафиксировать транзакцию через commit приводила к "disk I/O error". Проверка диска, анализ свободного пространства в tmpfs и на рабочих дисках ничего не дал. Попробовал для глючащей БД задавать PRAGMA temp_store=MEMORY, с нулевым результатом. И только через несколько часов выяснилось - новая версия SQLite отказывается нормально работать с файлом БД, размещенным на примонтированном NTFS разделе. Либо поддержка NTFS диска в этом дистре Линукса бажная и некоторые важные для ACID i/o функции не работают, либо вообще NTFS под линуксом теперь рассматривается ядром SQLite как моветон, в общем перенос создаваемой БД на родной линуксовый раздел всё исправил.
Теперь можно будет 1) зафиксировать в относительно близком времени текущий релиз SDK словаря 2) сделать наконец-то третий вариант SDK - полноценный серверный, пока только для MySQL, со словарем в MySQL и доступом через процедурный API solarix_grammar_engine_mysql.dll, то есть с полноценной поддержкой морфологического анализа и прочих вещей, недоступных в SQL-словаре.
Итак, в сухом остатке - для грамматического движка сделан и выполнен многопоточный нагрузочный тест. Это когда несколько (от 3х до 11) потоков одновременно вызывают sol_MorphologyAnalysis и sol_SyntaxAnalysis для одного экземпляра загруженного словаря, и сравнивают результаты для примерно 6000 эталонных английских предложений.
Раньше такой тест у меня был только для MS Windows варианта движка (32 и 64 битные dll). Он отлично выявляет всю грязь в коде с точки зрения доступа из множества потоков. Особенно это касается кэшей для данных в SQL хранилище. Когда десять потоков запрашивают какой-либо кэш в режиме читателя, а один поток, не найдя нужные данные, хочет стать писателем и подгрузить что-то из БД, любая ерунда с синхронизацией очень быстро разрушает кучу и валит систему.
Под Linux тест использует "голые" pthread_xxx, я решил обойтись без ООП-оберток, чтобы не тащить в тесты дополнительные внешние зависимости. В целом все просто, принципиалтьных отличий от win-specific функций
В целом, под Linux нашлось несколько ошибок. В частности, пришлось переработать использование мьютексов, перевести часть в рекурсивный режим. Ну и самое главное - чтобы открытое соединение с SQLite базой нормально обслуживало множество параллельных потоков, пришлось и под Linux открывать БД с помощью sqlite3_open_v2 с флагом SQLITE_OPEN_FULLMUTEX.
Не обошлось и без некоторого шаманизма. Древняя версия libsqlite3 под моим линуксом отказалась выполнять sqlite3_open_v2, и я решил обновиться до текущей версии 3.7.11. Под Win либа скомпилировалась и заработала без каких-либо проблем. А под Linux неожиданно всплыла ошибка там, где я никак ее не ожидал.
При сборке словаря на одном из этапов, при выгрузке данных в sqlite-базу, попытка зафиксировать транзакцию через commit приводила к "disk I/O error". Проверка диска, анализ свободного пространства в tmpfs и на рабочих дисках ничего не дал. Попробовал для глючащей БД задавать PRAGMA temp_store=MEMORY, с нулевым результатом. И только через несколько часов выяснилось - новая версия SQLite отказывается нормально работать с файлом БД, размещенным на примонтированном NTFS разделе. Либо поддержка NTFS диска в этом дистре Линукса бажная и некоторые важные для ACID i/o функции не работают, либо вообще NTFS под линуксом теперь рассматривается ядром SQLite как моветон, в общем перенос создаваемой БД на родной линуксовый раздел всё исправил.
Теперь можно будет 1) зафиксировать в относительно близком времени текущий релиз SDK словаря 2) сделать наконец-то третий вариант SDK - полноценный серверный, пока только для MySQL, со словарем в MySQL и доступом через процедурный API solarix_grammar_engine_mysql.dll, то есть с полноценной поддержкой морфологического анализа и прочих вещей, недоступных в SQL-словаре.