Hozzászólások
-
Bejegyzés
-
„memória gyorstár mérete: 256 MB”
Inkább legyen kevesebb, ha nincs min. 512MB RAM a gépben. Ha egy kicsit is használ a gép a swap-ból, drasztikusan esik a teljesítmény.„lemezes gyorstár mérete: 2 MB”
Több kellene, hogy ne csak az aktív tartalmat gyorstárazza.„átlagos (max)fájlméret: 10 KB”
Csak a max-ot lehet beállítani, annak meg nagyon kevés, 100-500kB az ajánlott.„alkönyvtárak száma: 256”
Szerintem a 256/1GB az optimális.Teljesen mindegy akkor a fájlrendszer típusa. A követkrző paraméterek korlátozák leginkább a squid teljesítményét: memória gyorstár mérete, lemezes gyorstár méretének és az átlagos (max) fájlméret aránya, alkönyvtárak száma, merevlemez elérési ideje.
Ja igen, a squid szeret hatalmas mennyiségű fájlt tárolni (1GB-ként pár százezer fájl). Nem árt bekapcsolni a vmi fast inode hashing (nem tudom a pontos nevét) opciót.
Tehát szerinted (uzsolt Őméltóságának):
1. ott voltál és tudod, hogy még véletlenül sem lett bekapcsolva integrált eszköz (vagy bármi ami memóriát hasít ki)
2. a hülyebiztos disztribeknek tilos összeadni a szétvágott memória darabokat
3. nem lényeges, hogy épp 128MB a különbség
4. rajtad kívül nem tudhat senki sem többet
5. nem lényeges a kérdező mit válaszol a postomra
6. bunkósággal sok mindent lehet pótolniHa többezer gépet kell kiszolgálni, akkor más paraméterek sokkal jobban befolyásolják a squid teljesítményét (pl. rendszergazda felkészültsége), ha ennél kevesebb, akkor a fájrendszerek közötti sebesség különbség hasonló mértékű, mint a zöld és kék színű autó közötti (beleértve a játékautókat is).
A kérdezőnek: 95%-os valószínűséggel integrált videókártyád van (ha nem használod mert van külön kártya, tiltsd le), ezért tűnik el a memória egy része. Valójában nem tűnik el, mert video memóriaként látszik (128MB).
A többieknek: miért kell mindíg mindenkit bevinni az erdőbe? Ez olyan LinuxFórumos dolog?
Egy kis pihent agyú puffer (csak a lényeges részt írom):
Code:class Buffer {
protected:
void * buf;
public:
HulyebiztosMutato operator* ();
};template
class HulyebiztosMutato {
protected:
T * ptr;public:
HulyebiztosMutato (T * p): ptr (p) {}inline T operator[] (int num) { return ptr[num]; }
inline T operator* () { return *ptr; }
inline T* operator-> () { return ptr; }
void operator delete [] (void * p) {
std::cerr << "Kedves programozó, menj inkább kapálni!" << std::endl;
::exit (666);
}
void operator delete (void * p) {
std::cerr << "Kedves programozó, szúrd magad tökön mielőtt kapálni indulnál!" << std::endl;
::exit (-666);
}
};Kinek mi a véleménye róla, hogy lehet szépen és biztonságosan használni egy C++ változót?
A variáns:
Code:int &operator[] ( size_t n ) {
return valami [ n ];
}B variáns:
Code:int &operator[] ( size_t n ) {
return this->valami [ n ];
}C variáns:
Code:int &operator[] ( size_t n ) {
return foo::valami [ n ];
}Egy példa a friend használatára:
Code:class ElemKontener {
friend class foo;
protected:
int & elem;// Nem publikus konstruktor
ElemKontener (int & src):
elem (src) {
}private:
// Nem másolható!!!
ElemKontener ( const ElemKontener & src);
ElemKontener & operator = ( const ElemKontener & src);public:
int operator= ( size_t src ) {
(…)„Bejelentek egy mutatot arra az osztalyra”
Ez így értelmetlen.„Az lenne a kerdes, hogy egy _mutato_ indexeles operatorat lehet-e felulbirlani?”
Közvetlenül nem, mert nem osztály, hanem beépített minősítő a mutató (mint pl. a const). Viszont mutató helyett lehet használni osztályt (pl. Buffer), és ennek az indexelését lehet felülbírálni.„Eselteg egy ilyennel ? Ezt a fordito nem hajlando megenni”
Nemis fogja. Nem tudom mi a szándékod, de ilyet lehet:Code:class valami: public Jo_Hosszu_NamSpace::Buffer {
public:
int & operator [](int) {
// A Jo_Hosszu_NamSpace::Buffer::operator[]
// helyett fog lefutni.
}
};Indexelés és értékadás túlterhelés kombinációja (vizsla kódját felhasználva – utólagos engedelmével):
Code:class ElemKontener {
protected:
int & elem;public:
ElemKontener (int & src):
elem (src) {
}int operator= ( size_t src ) {
// Pl. egyedi konverzió
if ( src > 1000 )
std::cerr << "Hiba: " << src << std::endl;
else
elem = (int)src;
return elem;
}int operator= ( char * src ) {
std::string s ( src );
if ( s.find_first_not_of ("-+0123456789e") != s.npos )
std::cerr << "Hiba: " << src << std::endl;
else
elem = atoi ( src );
return elem;
}int operator= ( std::string src ) {
if ( src == "egy")
elem = 1;
else if ( src.find_first_not_of ("-+0123456789e") != src.npos )
std::cerr << "Hiba: " << src < () {
return &elem;
}
};class foo {
protected:
int *valami;public:
ElemKontener operator[] ( size_t n ) {
return ElemKontener ( this->valami [ n ] );
}
};(Egy picit elcsúszott, hála a WYSIWYG módnak)
Teszteltem egyet. A lassabb gyorsabb lett. Egy lefordított progin a ccache újrafordítás sebességét mértem (semmit sem fordított a gcc). Lassabb lett a feldolgozás 2 szálon 3 másodperccel (real), de összességében 25 másodpercet lehetett nyerni az átfedésekkel (real). Ez azért nem jellemző, a ccache-nek sokkal nagyobb a lemezforgalma, mint egy gcc fordításnak. Most nincs időm ccache nélküli fordítási időket összehasonlítani.
-j1:
Code:real 2m38.319s
user 1m17.167s
sys 0m28.503s-j2:
Code:real 2m13.610s
user 1m20.289s
sys 0m29.222s„Ez akkor 100%-ig igaz, ha mást nem kalkulálsz bele. (Merevlemez milliárdx lassabb…)”
Így igaz. De egy viszonylag egyszerű magyarázatba több nem fért bele. Amit írtam az mindíg érvényes, kivétel nélkül. Úgy tippelem, hogy a két hatás (gyorstár csökkenés+lemez olvasási átfedés) egy teljes C++ fordításnál (nincs ccache) nagyjából kiolthatja egymást.„Persze a franc tudja, hogy hogy osztja ki a feladatokat a make. Ha rosszul csinálja, akkor a visszájára is elsülhet…”
Hát, az összes ‘make -C’ sopompóként működik, bevárja az összes szál végrehajtását. Azaz a sok alkönyvtár lassítja a párhuzamos fordítást.
