Sziasztok!
Van egy régi vas, az alábbi hardver tartalommal:
ALAPLAP: Tyan Tiger MP 1.05
CPU: 2xAthlon 1200
MEM: 512M (2x256M, de lesz ez 768M vagy 1024M is :) )
1. RAID: IBM ServeRaid-4Lx (PCI-X)
2. RAID: Adaptec AHA2110S (PCI-X)
NET: 3COM-905B
Azért pont ez az alaplap, mert a raidvezérlők miatt (valójában csak az AHA2110S miatt) kellenek a 64bites PCI slot -ok.
Ezen fognak futni az alábbiak:
- FreeBSD 7-STABLE
- Apache2+php
- PostgreSQL
- Postfix+*
Használat, terhelés:
Feladata: helyi viszonyokra írt, közös (php -ben megírt) adatkezelés megvalósítása, telefonközpont híváslog sql -be mentése, stb...
Nem túl nagy terhelés, azaz: nem hasznájuk sokan.
Konkurrens (php-felület) használat: 2. Néha, nagyritkán 3 -an egyszerre.
Nagymennyiségű adatbevitel: általában havonta 1-szer a feldolgozott, beárazott híváslog (SQL-COPY)
Kismennyiségű (állandó) adatbevitel: társközpontból híváslog (radius -on keresztül), ill. céges központ nyers (text) híváslog. Nappal: 3....10rekord/perc, éjjel: 3....10rekord/óra.
Manuális adatbevitel: 5...40 űrlap/nap
Manuális adatlekérdezés: n*10 űrlap/nap (néha ez jóval több, de enm mindig)
A php -s felület jelenleg egy másik gépen is fut. Ezen csak "elérhetőségi tartalék" gyanánt van fent.
Némelyik lekérdezés viszont nagyon lassúnak tűnik.
Talán azért is, mert elég sokminden szét van bontva külön táblákra. Pl.: egy teljes-szervezeti-info-lista lekérés (view neve: unit_hier_current) "csak" 12 kapcsolt (inner és left join -ok) táblából áll, valamint 2 oszlopba külön függvény adja az adatokat.
Persze nem minden ennyire bonyolított, de a legöbb SELECT nem "egytáblás".
Ennek fényében mit érdemes tuningolni a PostgreSQL -en?
Érdemes egyáltalán tuningolni bármit is?
Milyen blokkméreteket érdemes beállítani? (filesystem blocksize, raid stripe size, PostgreSQL blocksize)
Megj.: tudom, hogy "nem valami erős gép", de eddig (~2003 közepétől) az alábbiak voltak:
1. Celeron-533, 256M (majd később 384M) ram, ...
2. Celeron-766, 384M (később 512M) ram, Mylex DAC960 -as raid, szalagos mentés, stb...
3. dual-P2-450, 512M (utána 768M) ram, on-board "aha2940", mylex raid, hotswap scsi keret
A válaszokat előre is köszönöm.
--
vaxx
- 1109 megtekintés
Hozzászólások
selectek optimalizálása? (ami sokáig fut, azt megplanelni, ha kell rakni rá indexet, hint-et...)
- A hozzászóláshoz be kell jelentkezni
A rendszert régóta fejlesztem. Az index -ek már régen megvannak. Index -ek nélkül sokkal katasztrófálisabb eredményt (sebességet) kapok. Így még ahasznáhatóság határán van.
Gondolom, hogy akik ezt olvassák, azokban felmerült a kérdés, hogy "miért kellett ez"?
Válaszom: azért, mert eredetileg az alábbi részekre volt szétszedve (alábbi helyeken kezelték) a sok-sok redundánsnak kikiáltott adatot, és iszonyat könnyen kiesett a szinkronból.
A külön részek (külön helyek) nagy vonalakban:
1. telefonközpont admin (kategóriák, kódok, mellék-szervezet összerendelés, stb...)
2. hálózatosok (épület-emelet-ajtó, mellék-szervezet összerendelés, kábelezés)
3. telefonkönyv (mellék-szervezet, és mellék-épület-emelet-ajtó összerendelések)
4. hangposta és díjszámláló kezelője (ez lennék én)
5. külsős szervezeti egységek kapcsolattartója (telefonos ügyekben)
6. céges telefon referens
Ameddig a jelenlegi közös rendszer nem volt, addig volt olyan, hogy egy hónapban 2x (de néha 3x is) jártunk a "szőnyeg szélén", és ment a mutogatás...
- A hozzászóláshoz be kell jelentkezni
+1 a lassú selectek elemzésének.
Nálam okosabb és autentikusabb doksi szerint ez is megszívlelendő:
"PostgreSQL does not seem to generate good plans if you do a join with a view. In this case you should try to recreate the query using the tables in the view explicitly." Forrás (hasznos máshoz is) itt.
- A hozzászóláshoz be kell jelentkezni
shm-et adj neki rendesen :)
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni