Товаров:
Jak tylko rozmiar 1C: Baza danych plików korporacyjnych jednego z naszych klientów osiągnęła rozmiar 32 GB (tak, 32 GB), w wyniku czego wszystko stopniowo zaczęło zwalniać, a następnie spadło, nasi klienci poprosili nas o rozwiązanie tego problemu. Klasa SSD Enterprise osłodzi pigułkę na chwilę, ale po chwili wszystko wróciło do punktu wyjścia. Cóż, tutaj i nie idź do babci - przejdź do wersji SQL bazy danych.
Ponieważ jesteśmy gorącymi użytkownikami systemu Windows, dostępne są tylko dwa warianty DBMS - są to MSSql i PostgreSQL. Pierwszy jest dobry do szaleństwa, ale koszt nie jest zadowolony. Jeszcze więcej nie było zadowolonych z wiadomości o dodatkowych licencjach 1C do pracy z MSSQL. Dlatego PostgreSQL.
Szczegółowe instrukcje z dostępnym wideo. tutaj . W tym artykule przejdziemy przez kluczowe punkty.
Nie zapomnij o z powrotem Bazy danych 1C!
Linia bazowa:
- Windows Server 2008R2,
- Intel Core i7-2600K 3,40 GHz,
- 32 GB pamięci RAM,
- Intel SSD DC3700 100 Gb (tylko dla DB, OS na osobnym dysku SSD),
- codziennie od 10 do 20 użytkowników w bazie danych,
- wymiana z 5 węzłami rozproszonej bazy danych w tle.
Złowrogi, prawda? Zacznijmy
1. Instalowanie PostgreSQL i pgAdmin.
Brak informacji o tym, skąd będzie pobierany PostgreSQL - to nasza ulubiona strona. https://releases.1c.ru , sekcja „Dystrybucja technologiczna”. Pobierz, ustaw. Nie zapomnij zainstalować BIBLIOTEK RUNTIME MICROSOFT VISUAL C ++ 2010 z pakietem serwisowym 1, który jest dołączony do archiwum z zestawem dystrybucyjnym. Oni sami na to wpadli: nie zainstalowali go, doświadczyli dużo bólu.
Dalej wszystko układamy dalej, z wyjątkiem następnych chwil. Ustaw jako usługę (zaznacz) i ustaw parametry konta Windows, a nie PostgreSQL.
Zainicjuj klaster bazy danych (zaznacz). I tutaj ustawiamy parametry konta dla PostgreSQL! Ważne: musisz mieć uruchomioną usługę Logowanie pomocnicze (lub zlokalizowane systemy operacyjne: „Logowanie dodatkowe” ). Kodowanie UTF8 jest również ważne!
Co więcej, nic ciekawego. Więcej ...
pgAdmin jest trochę stary w tej kompilacji. Idziemy do https://www.postgresql.org/ftp/pgadmin3/release/ . W chwili pisania tego tekstu najnowsza wersja 1.22.1. My to huśtamy. Idziemy.
Podczas procesu instalacji przystawka „Enterprise 1C Servers Administration” nie zostanie zatrzymana. To jest zupełnie inny temat. Tak, i nie ma nic skomplikowanego.
Tworzymy bazę danych SQL w tej przystawce, sprawdź w pgAdmin - baza danych pojawi się tam, jeśli wszystko jest poprawne.
2. Dostrajanie PostgreSQL 9.4.2.
Następnie wjeżdżamy w nasze głowy: przed zapisaniem nowych ustawień, wykonaj kopie zapasowe plików:
- pg_hba.conf
- postgresql.conf
- pgpass.conf
które tu leżą:
C: Program Files PostgreSQL 9.4.2-1.1C Informacje
Jeśli popełnisz błąd nawet w jednej literze, po aktualizacji konfiguracji PostgreSQL nie uruchomi się. Trudno będzie ustalić, co go spowodowało, nawet patrząc na dzienniki systemu Windows. Dlatego nie zmieniaj wielu parametrów jednocześnie i twórz kopie zapasowe.
Aby edytować konfigurację, dostępne jest wygodne narzędzie dostępne bezpośrednio z głównego okna pgAdmin. Oto jest:
Co tu zmieniamy:
- shared_buffers - Ilość pamięci przydzielonej przez PgSQL do udostępniania pamięci podręcznej stron. Ta pamięć jest wspólna dla wszystkich procesów PgSQL. Dzielimy dostępną pamięć RAM na 4. W naszym przypadku jest to 8 GB.
- efficient_cache_size - Oszacuj rozmiar pamięci podręcznej systemu plików. Uważa się, że: RAM - shared_buffers. W naszym przypadku jest to 32 GB - 8 GB = 24 GB. Ale osobiście pozostawiam ten parametr jeszcze niżej, gdzieś 20 GB - w końcu RAM jest potrzebny nie tylko dla PostgreSQL.
- random_page_cost = 1.5 - 2.0 dla RAID, 1.1 - 1.3 dla SSD. Koszt odczytu losowej strony (domyślnie 4). Im mniej czasu wyszukiwania systemu dyskowego, tym mniej (ale> 1,0) tego parametru powinien być. Niepotrzebnie duża wartość parametru zwiększa tendencję PgSQL do wybierania planów ze skanowaniem całej tabeli (PgSQL uważa, że taniej jest konsekwentnie odczytywać całą tabelę niż indeks losowy). I to jest złe.
- temp_buffers = 256Mb . Maksymalna liczba stron dla tabel tymczasowych. Oznacza to, że jest to górna granica rozmiaru tabel tymczasowych w każdej sesji.
- work_mem - Uważa się, że: RAM / 32..64 - w naszym przypadku okazuje się, że 1 GB . Limit pamięci do przetwarzania pojedynczego żądania. Ta pamięć jest indywidualna dla każdej sesji. Teoretycznie maksymalna wymagana pamięć jest równa max_connections * work_mem, w praktyce nie występuje, ponieważ większość sesji prawie zawsze zawiesza się.
- bgwrite_delay - 20ms. Czas uśpienia między cyklami zapisu do procesu zapisywania w tle dysku. Ten proces jest odpowiedzialny za synchronizację stron znajdujących się w dzielonych buforach z dyskiem. Zbyt duża wartość tego parametru zwiększy obciążenie procesu punktu kontrolnego i procesów obsługujących sesję (backend). Niska wartość spowoduje pełne obciążenie jednego z rdzeni.
- synchronous_commit - off . NIEBEZPIECZEŃSTWO! Wyłącz synchronizację dysku w momencie zatwierdzania. Stwarza to ryzyko utraty kilku ostatnich transakcji (w ciągu 0,5-1 sekundy), ale gwarantuje integralność bazy danych, w łańcuchu zatwierdzeń nie ma luk. Ale znacznie zwiększa wydajność.
Nie jest to wszystko, czego nauczyliśmy się z Internetu i artykułów na ten temat https://its.1c.ru . ALE! Nawet te ustawienia będą wystarczające do przyspieszenia pracy 1C: Enterprise w PostgreSQL.
W tym konkretnym przypadku, po przejściu na PostgreSQL, użytkownicy zaczęli narzekać, że 1C zaczął zwalniać jeszcze bardziej niż w wersji pliku. Ale po tym tuningu baza „poleciała”. Teraz wszyscy cieszą się szybką pracą. Istnieją jednak również wady w postaci zamków. Nie zamierzamy się nad tym zastanawiać, będziemy kopać dalej i zamieścić tutaj przydatne zmiany w konfiguracji PostgreSQL.
Jeśli są jakieś problemy z bazą danych, może ci to pomóc. testy wewnętrzne lub zewnętrzne .
Baza danych 1C może publikuj na serwerach internetowych !
Złowrogi, prawda?