Jak wykorzystać specyfikę Linuxa do przyspieszenia aplikacji?

0

Cześć!

Pracuję obecnie nad aplikacją, która ma załadować ogromną ilość danych do pamięci i po nich wyszukiwać.
W związku z tym mam pytanie:

(nie znam się na programowaniu systemowym)
Czy są jakieś sposoby na przyspieszenie szybkości działania aplikacji wykorzystując fakt, że piszemy akurat na Linuxie?
Może jakaś specjalna obsługa pamięci albo coś w tym stylu? (teraz tak gdybam)

Proszę o jakieś info z Waszego doświadczenia gdzie się zaczepić, w którą stronę pójść.
Dzięki z góry!

1
  1. Co to znaczy ogromną? Zmieścisz w pamięci czy nie zmieścisz?
  2. Jaki jest rodziaj tego wyszukiwania?
    2.1 proste tekstowe i można wrzucić to do elastica?
    2.2 bardziej SQL i np Apache Spark by sie przydał?
5

@tańcząca żyrafa:

Za ChRL nie rozumiem szczegółów.
Z ciekawostek - których jak napisałem nie rozumiem - są pliki mapowane jako obszar pamieci RAM. To czasem sie do czegoś przydaje.

Nie dajesz zadnych szczegółów, jak "dużo", czy na miarę pamięci RAM, czy więcej.
Na ile jest wolno? Jak jest wiecej niż szkolne 10-100 sztuk, warto używac właściwych optymalnych rozwiazań algorytmiki, a nie rżnąć na siłę "algorytmami naiwnymi". O tym tez milczysz
Np nie szukanie pętlami, a zosrganizowanie struktur odpowiednio do zagadnienia (np -strzelam - mapy/słowniki )

Mówiąc językiem twojego pytania: lepiej wykorzystać specyfikę algorytmiki

3

nie wiem może zacząć drążyć od takiego tematu
memory mapping

0
KamilAdam napisał(a):

2.1 proste tekstowe i można wrzucić to do elastica?
2.2 bardziej SQL i np Apache Spark by sie przydał?

Ja bym z szacunkiem powiedział o PROSTYCH bazach NoSQL key-value jak berkeley i pochodne - z tym że OP milczy o jakich wielkościach mowa, czy przekracza RAM

0
ZrobieDobrze napisał(a):
KamilAdam napisał(a):

2.1 proste tekstowe i można wrzucić to do elastica?
2.2 bardziej SQL i np Apache Spark by sie przydał?

Ja bym z szacunkiem powiedział o PROSTYCH bazach NoSQL key-value jak berkeley i pochodne - z tym że OP milczy o jakich wielkościach mowa, czy przekracza RAM

Ja tych prostych baz KV nigdy nie rozumiałem. Ma ktoś dowód że to szybsze od PostgreSQLa? Bo chyba że siedziw w pamięci jak Redis. Ale wtedy równie dobrze można wczytać to sobie do HashMapy, jak mamy tylko jedną instancję programu szukającego

3

W sumie to można by to pytanie przeformatować na - Czy jest jakiś use case gdzie używanie sys calli może przyspieszyć program? To nawet ciekawe pytanie, bo nie znam żadnego takiego przypadku (co nie znaczy że takiego nie ma). Wszelkie architektoniczne optymalizacje zakończone sukcesem z jakimi miałem styczność, polegały na podejściu zgoła odwrotnym, czyli jak najmocniejszej separacji aplikacji od systemu i przenoszeniu wszystkiego co się da do user space.

2
tańcząca żyrafa napisał(a):

Cześć!

Pracuję obecnie nad aplikacją, która ma załadować ogromną ilość danych do pamięci i po nich wyszukiwać.

Może lepiej przemyśl w jaki sposób chcesz wyszukiwać dane. Poczytaj o złożoności algorytmicznej, strukturach danych, drzewach wyszukiwań itp. (tak rzucam hasłowo, bo mam wrażenie, że to pytanie to rozwiązywanie problemu w niewłaściwy sposób, czyli problem XY: https://en.wikipedia.org/wiki/XY_problem ). Chyba, że już masz dobrze zoptymalizowane struktury i pytasz faktycznie o to, o co naprawdę pytasz, czyli konkretnie o specyfikę Linuxa.

ogromną ilość danych do pamięci

Nad tym też należałoby się zastanowić - czy faktycznie musisz załadować ogromną ilość danych do pamięci za każdym razem, kiedy chcesz coś wyszukać. Czy może lepiej zrobić sobie jakieś indeksy (jak w bazie danych, ale można to samemu zaimplementować*) i potem tylko wczytywać indeksy itp.

*albo użyć po prostu gotowej zewnętrznej bazy danych jak np. Postgres czy silnika wyszukiwań jak np. ElasticSearch. Ogólnie to zależy, co chcesz zrobić, ale nie podałeś wielu informacji

0

Zaopatrz się w jakiś wielki system z terabajtami RAM-u, utwórz sobie ramdysk lub zamontuj jako tmpfs-a i może będzie ok :) Nie podałeś wielkości zbiorów stąd trudno gdybać co byłoby najlepsze.

1

Z mojego doświadczenia, jak są problemy z ilością pamięci to zmień strukturę danych.
Np. niezbędne było załadować mapę miasta dostępna w formacie GIS do pamięci arduino (jak wiadomo nie gęsto z tą pamięcią) sterującym dronem.
Więc listę punktów w formacie { szerokość geograficzna, długość geograficzna, wysokość p.p.m. } wystarczyło przekształcić w dwuwymiarową tablicę wysokości z dokładnością do 1m oraz jednym punktem { szerokość geograficzna, długość geograficzna } lewego górnego rogu.
Panaceum nie istnieje, a jak się znajdzie to natychmiast zostanie wdrożone w architekturę komputerów lub w algorytm optymalizacji.

0

Okey, mówiąc o dużej liczbie danych nie mam na myśli jakichś niesamowitych baz danych - po prostu mam plik csv z którego muszę odczytać około 5 milionów rekordów i wyszukiwać w tych odczytanych danych jak najszybiej.
Nie pisałem o tym, bo nie chciałem odrywać uwagi od samej kwestii Linuxa.

3

Przeoraj ten CSV załaduj go do bazy lub do innej struktury nadającej się do szybkiego wyszukiwania.
... ponieważ jeżeli chodzi o wyszukiwanie to gorszy od csv chyba tylko xml.

1
tańcząca żyrafa napisał(a):

Okey, mówiąc o dużej liczbie danych nie mam na myśli jakichś niesamowitych baz danych - po prostu mam plik csv z którego muszę odczytać około 5 milionów rekordów i wyszukiwać w tych odczytanych danych jak najszybiej.
Nie pisałem o tym, bo nie chciałem odrywać uwagi od samej kwestii Linuxa.

jeśli zasada szukania da się określić jasno, "na jeden strzał", to podczas DOBREGO czytania np w C/C++ (tzn: należy czytania nie spieprzyć, zwłaszcza w C++ można tu się negatywnie wykazać), if'em ocenić wiersz, wykonać algorytm itd...
Nic nie będzie szybsze od jednego DOBREGO czytania, bo i przez bazę danych ten etap jest nieunikniony jako wstępny

else

w każdym innym przypadku (zwłaszcza: będziesz eksperymentował z warunkami szukania) baza, raz import -> podejścia analityczne jedno za drugim

(jak baza to temat praktycznie nie ma już nic wspólnego z C++, to jeden z gorszych jezyków)

0
tańcząca żyrafa napisał(a):

Okey, mówiąc o dużej liczbie danych nie mam na myśli jakichś niesamowitych baz danych - po prostu mam plik csv z którego muszę odczytać około 5 milionów rekordów i wyszukiwać w tych odczytanych danych jak najszybiej.
Nie pisałem o tym, bo nie chciałem odrywać uwagi od samej kwestii Linuxa.

Jeśli z jakichś powodów nie chcesz w całości tego CSV-a trzymać w pamięci - tylko chcesz sobie doczytywać fragmenty z pliku to tak jak pisałem wcześniej - użyj tmpfs-a. Zastanawiam się, czy jest jakiś szybszy filesystem do odczytu i zapisu...

4

System operacyjny nie pomoże jak koncepcja kiepska bo nawet tmpfs nie uratuje skopanych rozwiązań.

5
tańcząca żyrafa napisał(a):

Okey, mówiąc o dużej liczbie danych nie mam na myśli jakichś niesamowitych baz danych - po prostu mam plik csv z którego muszę odczytać około 5 milionów rekordów i wyszukiwać w tych odczytanych danych jak najszybiej.
Nie pisałem o tym, bo nie chciałem odrywać uwagi od samej kwestii Linuxa.

5 milionów rekordów dla współczesnego komputera to niewiele.
Podaj więcej szczegółów: ile jest kolumn, jakiego są typu, jaka jest logika wyszukiwania.
Te 5 milionów rekordów powinno się zmieścić w pamięci, więc jedyny problem to stworzenie takiej struktury danych, by wyszukiwanie miało niską złożoność czasową.

2

Co do samego przetwarzania 5M rekordów, to sama ich ilość nie powala. To co może być istotne, to jak często wyszukujesz. Zakładam, że dużo i jakieś mikro optymalizacje mogą mieć sens.

Skoro dane będą do odczytu i od strony aplikacji zrobisz wszystko co się da (odpowiednie struktury danych), to pozostaje część systemowa. Szybszego wyszukiwania niż w pamięci nie zrobisz, więc tu trzeba szukać optymalizacji (w drugiej kolejności, bo w pierwsze to struktury danych i algorytmy).

Jeśli chodzi o wsparcie ze strony OS, to masz koncept Huge Pages (Linux), czy Large Pages (AIX,Windows). Standardowo strona pamięci ma określony, niewielki, rozmiar (np. 4kb), zaś huge pages pozwalają operować systemowi operacyjnemu na dużo większych blokach (MB, GB) - przez to będzie mniej wpisów w TLB -> szybszy lookup.

Kolejna rzecz, mlock, strony pamięci można przyblokować, tzn. wymusić, żeby były w pamięci fizycznej, dzięki temu unikniesz wpływu page in/page out.

0

ja to chciałbym zwrócić uwagę na STL od c++17 i możliwości ExecutionPolicy w niektórych algorytmach jak search, is_sorted itd. Czyli niektóre algorytmy mogą się "same" zrównoleglać jak mają odpowiednie policy. Czyli może ci to pomoże w twoim opracowywaniu algorytmu do wyszukiwania. Czy tak będzie nie wiem ale zwracam uwagę.

0
tańcząca żyrafa napisał(a):

Cześć!

Pracuję obecnie nad aplikacją, która ma załadować ogromną ilość danych do pamięci i po nich wyszukiwać.
W związku z tym mam pytanie:

(nie znam się na programowaniu systemowym)
Czy są jakieś sposoby na przyspieszenie szybkości działania aplikacji wykorzystując fakt, że piszemy akurat na Linuxie?
Może jakaś specjalna obsługa pamięci albo coś w tym stylu? (teraz tak gdybam)

Proszę o jakieś info z Waszego doświadczenia gdzie się zaczepić, w którą stronę pójść.
Dzięki z góry!

Możesz zacząć od posortowania tych danych.
Zasadniczo to odczucie mam takie, że ta aplikacja jeszcze nawet nie miała okazji powstać i być zbyt wolną.
Wątpię aby mmap tu coś pomogło. Ale jest to jakaś tam myśl.
Trochę mało informacji.

Po łebkach czytałem to co inni napisali. Więc pewnie już wszystko wiadomo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1