Progress, Unix, Linux

[Piotr.Korpas@alcatel.pl]

Szanowna Pani,

Przede wszystkim prosze sprobowac okreslic co najbardziej obciaza
system ? Warto sprawdzić na co faktycznie jest przeznaczany czas obu 
procesorow i jakie jest ich obciazenie.  Jezeli jest niewielkie to
problem wydajnosci nie jest zwiazany z moca maszyny i przyczyn
niskiej wydajnosci nalezy szukac gdzie indziej.

Poza tym z czego uzytkownicy sa niezadowoleni ?
Czy zbyt dlugo trwa sporzadzanie raportow i zestawien (odczyt),
czy tez system "zawiesza sie" przy wprowadzaniu danych (zapis). 
Byc moze znacznym obciazeniem dla systemu jest kilku uzytkownikow,
ktorzy uruchamiaja olbrzymie raporty. Jezeli tak, to moze warto 
pomyslec o drugiej maszynie wykorzystywanej tylko do raportowania.
Koszt jest spory (serwer + licencje), ale mozna go zmniejszyc ograniczajac
liczbe licencji Progress'a na drugiej maszynie.

Czy nie warto zwiekszyc pamieci RAM i przeznaczyc na bufory bazy (-B) ?
Nie znam dobrze wersji Prgs. 9.1 i SCO Unix, ale jeżeli blok bazy jest 1 
kB, to -B = 28 MB
jest stanowczo za małe. Moim zdaniem powinno wynosić choć z 10 % wielkości 

bazy czyli 600 MB, gdy tymczasem całej pamięci mamy 512 MB. W wersji 8 i 9
mozna zmieniac rozmiar bloku bazy. Warto go zwiekszyc maksymalnie

Jak faktycznie wygląda konfiguracja dysków ? Ile jest fizycznych dysków i
jak są połączone. Czy pisze Pani o 4 logicznych wolumenach po 18 GB
składających się z NN dysków połączonych w mirorringu i stripingu czy 
o 4 fizycznych dyskach po 18 GB połączonych... no wlasnie jak ?
Dobrze jest miec choc 6 dyskow polaczonych w pary (mirroring),
2 wolumeny przeznaczyc na minimum dwa ekstenty DB, jeden na BI.
Mozna starac sie stosowac ekstenty o malym rozmiarze (np. 30 x 200 MB),
ale nalezy pamietac o koniecznych zmianach w systemie operacyjnym.

Czy sa uruchomione procesy wspomagajce zapis PROAPW, PROBIW ?
Aby polepszyc zapis warto zwiekszyc rozmiar klastra BI oraz
rozmiar bloku BI, choc w Prgs. 9.1 byc moze standardowe ustawienia sa 
wystarczajace. Nie nalezy obcinac pliku BI, ale utrzymywac staly dosc
duzy rozmiar. Z jednej strony nie moze byc zbyt duzy (po co archiwizowac
niewykorzystane miejsce dysku), z drugiej strony aktywnosc uzytkownikow
nie powinna powodowac zwiekszania jego rozmiaru. Nalezy okresowo 
sprawdzac, czy rozmiar BI nie osiagnal wartosci granicznych.
 
Jacy klienci "self-service" czy "remote" podlaczaja sie do bazy ?
Czy korzysta sie z polaczen ODBC ?

HTH,
Piotr Korpas.






Łucja Bielas 
Wysłane przez: owner-progress@zeto.bydgoszcz.pl
16.05.01 09:02
Odpowiedz do progress

 
        Do:     
        DW: 
        Faks do: 
        Temat:  Progress, Unix, Linux





Witam ponownie,
 
Jestem użytkownikiem aplikacji progressowej. Baza progressowa 
wielowolumenowa ma prawie 6 GB. Całość jest na serwerze  unix-
owym. Szybkość działania systemu jest niezadawaljąca. 
Wiadomo, nowy serwer to duży wydatek.
 
Podaję szczegóły dotyczące mojego  problemu.
 
Serwer: Compaq ProLiant 3000 z dwoma procesorami P II  500MHz,
               dyski 4x 18 GB w mirroringu i streeppingu,
               RAM  512MB.
Progress: wresja 9.1 - 45 użytkowników.
Unix: SCO Open Server 5.04
Baza była przeładowana rok temu. Bi bazy jest na innym dysku niż 
sama baza. Rozmiar Bi 14MB. 
Parametry servera bazy: 
-B 28672 -L 18000 -Mn 1 -n 45 -s 1000
 
Pytanie:
Czy baza i aplikacja progressowa mogą działać sybciej na  Linuxie ?
Czy warto zmieniać platformę z Unixa na Linuxa ?
 
Z góry dziękuję za wszelkie informacje.
 
Łucja 


------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------