NTP setzt systemzeit bei überlasteter maschine falsch
Hallo, auf meinem Backupcomputer läuft /usr/sbin/ntpd aus dem woody ntp-simple paket. Er hat 512 MB Hauptspeicher und ist ein Pentium 4 mit 1.8 GHz. es laufen große rsync prozesse der art: (ps axwum) root 8971 35.8 0.6 67744 3220 ?S05:13 38:44 rsync -vax --delete --stats --delete-excluded /backups/ /wechselplatt... root 8972 1.9 25.6 134684 132132 ? S05:13 2:04 rsync -vax --delete --stats --delete-excluded /backups/ /wechselplatt... root 8989 33.6 20.1 134684 103380 ? R05:31 30:29 rsync -vax --delete --stats --delete-excluded /backups/ /wechselplatt... dabei ist die kiste total überlastet. es dauert schonmal 15 sekunden bis man eine ssh verbindung auf die maschine öffnen kann. diese rsync sachen laufen ein paar stunden und werden jede nacht per cronjob gestartet. jede nacht stellt der ntpd die systemzeit total kaputt. und am morgen danach beginnt er sie wieder zu reparieren. gibts keinen ntpd der sich bei systemueberlastung in zurueckhaltung uebt? MfG, Erik Thiele -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Qt - Memory Leak?
hi On Wed, 09 Jul 2003 23:49:13 +0200 Andreas Pakulat [EMAIL PROTECTED] wrote: On 09.Jul 2003 - 20:26:50, Patrick Schnorbus wrote: Mir ist etwas aufgefallen: 1) Ein Programm oeffnen, welches QTextEdit benutzt (z.B. kwrite) 2) Mit top o.ae. den Speicherverbrauch messen. 3) Viel Text einfuegen, so dass der Speicherverbrauch hochgeht. 4) Den Text wieder entfernen 5) Der Speicherverbrauch bleibt konstant oben. Es scheint so, als ob sich QTextEdit bei Bedarf neuen Speicher zwar allokiert, ihn aber nicht wieder freigibt, wenn er nicht mehr benoetigt wird. Kann das jemand reproduzieren? Ich verwende Woody mit Qt 3.1.2. Das ist durchaus drin. Wenn es dich stört, würde ich einen eigenen Editor schreiben. Zum Speichern des Inhaltes kannst du zum Beispiel eine STL Rope verwenden. Wenn das doch zu viel Aufwand ist, so lösche das QTextEdit und erzeuge ein neues. QString old=mytextedit-text(); delete mytextedit; mytextedit = new QTextEdit (this); mytextedit-setText(old); foolayout-insertbla(mytextedit,bla); irgendwie so. Eine ordentliche Editor Speicherverwaltung wäre zum Beispiel: Sobald der Edit Puffer überläuft, verdoppele seine größe. Sobald der Edit Puffer nur ein Viertel gefüllt ist, halbiere seine größe. Aber eine STL Rope sollte einfacher sein als alles selber zu machen und auch effizienter. Ich selbst habe für einen Editor mal zwei Auslagerungsstapeldateien verwendet. Der Bereich, der gerade editiert wird ist im Speicher. Er ist aber nicht größer als 32 KB (war ein DOS-Editor). Wenn man ein Zeichen einfügt, so werden die Zeichen in diesem Puffer nach rechts umkopiert und das Zeichen an der richtigen Stelle eingefügt. Läuft der Puffer über, so wird das Überlaufende auf den linken oder rechten Auslagerungsstapel gesetzt. Will man auf Zeichen links vom Puffer zugreifen, so wird rechts ausgelagert und links eingelagert (immer eine gewisse PAGESIZE gross), bis man angekommen ist. Ergo ist insert und delete immer gleicheffizient, egal wieviele Terrabytes der Text gross ist. Aber wehe du moechtest an den anfang oder das ende der datei springen, dann musst du die ganzen Stapel durchrollen. Übrigens ist Laden und Speichern solcher Files auch mit einem durchrollen verbunden... Die STL Rope ist irgendwie so ähnlich, nur aber komplett im Speicher. Aber evtl. kann man das korrigieren. Doku ist ziemlich gut. Übrigens das mit dem QTextEdit ist kein Memory Leak, denn der delete des QTextEdit gibt den Speicher frei. Aber wenn du deine Qt-Programme mal mit valgrind (debian paket) laufen lässt, so findest du echte Leaks :-) cya! erik -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: integer groesser 2^31 in C
On Sun, 29 Jun 2003 17:11:42 +0200 (CEST)
Achim Fritz [EMAIL PROTECTED] wrote:
Hi,
fuer ein Finite-Element-Programm in C, muesste ich unbedingt mehr als 2Gb
Speicher allokieren. Der Rechner hat 2Gb Speicher und 2Gb Swap.
du kannst nicht mehr als 4GB Speicher allokieren da der pointer datentyp 32Bit ist
(auf 32Bit Maschinen).
(void*) zum beispiel.
es ist auch nicht moeglich, mehrere 4GB bereiche zu allokieren, da in C der gesamte
allokierte Speicherbereich über Pointer zugänglich sein muss.
gleichwohl mag linux insgesamt mehr als 4GB RAM verwalten, so dass einzelne Prozesse
(nicht Threads!) jeweils die 4GB erreichen können.
Ich habe erst gedacht, es liegt am Kernel (CONFIG_HIGHMEM ist gesetzt),
habe jetzt aber festgestellt, dass es nicht moeglich ist in C eine Integer
zu deklarieren, die groesser als 2^31 ist.
zunächst einmal
#include sys/types.h
und dann:
u_int32_t
int32_t
usw. verwenden statt int und long long. sonst ist dein code nicht portabel.
datentypen wie int und long etc. sind per definition eine sünde und jede
programmiersprache die sie besitzt ist murx.
ausnahme zum beispiel das gute alte lisp, wo der datentyp int seinem
namen gerecht wird und _beliebig_ grosse zahlen aufnehmen kann.
doch zurueck zum thema, du musst also zunaechst einmal klarstellen, welche
datentypen du verwenden moechtest. jetzt zu deinem problem mit der zuweisung:
u_int32_t x = 4294967295;
-- mist.c:5: warning: decimal integer constant is so large that it is unsigned
das problem ist hier, dass der compiler die symbole zunaechst einmal einzeln parst.
er sieht eine ziffernfolge: 234879 und macht daraus ein Integer Symbol,
also eine Konstante vom Datentyp int. Je nach compiler und platform ergeben
sich daraus unterschiedliche limitierungen. bei einer 32bit maschine ist zum beispiel
2147483647 der groesstmoegliche wert. bei einer 16bit maschine ist es halt 32767.
dass du das hier in eine variable zuweisst, die den wert aufnehmen kann ist zu dem
zeitpunkt unbekannt. der compiler sieht einfach diese zahl und will sie einlesen.
ergo musst du ihm sagen, dass es sich hierbei um eine grosse zahl handelt:
u_int32_t x = 4294967295u;
siehst du das u am ende der zahl? das steht fuer unsigned. er soll also hier keinen
int lesen, sondern einen unsigned int. dann klappts auch, weil der wert da reinpasst.
das problem geht aber noch weiter:
u_int64_t y = 2u;
mist.c:6: integer constant out of range
das ding passt eben nicht in einen unsigned int. zumindest nicht auf einer
32bit maschine! also musst du machen:
u_int64_t y = 2ll;
ll steht fuer long long. ja richtig, der grosse mist mit unportablen datentyp-
groessenangaben setzt sich hier leider fort und alles ist wieder unportabel.
wenigstens kriegst du compiler errors wenn du das suffix hinten nicht richtig gemacht
hast.
wenn du jetzt an das limit vorzeichenloser 64 bit zahlen faehrst:
u_int64_t oo=18446744073709551615ll;
-- mist.c:7: warning: decimal integer constant is so large that it is unsigned
musst du eben das u wieder dazu machen:
u_int64_t oo=18446744073709551615ull;
das gesamte integer handling ist kacke in C und in den meisten anderen sprachen leider
auch.
Hab schon mehrere Compiler ausprobiert (unter anderem auch Borland auf
Windows) und in den manpage von gcc nach optionen gesucht.
(2.4.21 hab ich auch schon getestet)
es ist unabhaengig vom compiler. C ist so definiert.
Der Kernel hat auch keine Probleme mit grossen Zahlen:
[EMAIL PROTECTED]:~/ugspeicher/test-proc echo 2^31|bc
2147483648
[EMAIL PROTECTED]:~/ugspeicher/test-proc echo 2^32|bc
4294967296
[EMAIL PROTECTED]:~/ugspeicher/test-proc echo 2^100|bc
1267650600228229401496703205376
das hat nichts mit dem kernel zu tun. bc ist ein programm,
und das kann es halt.
Hat jemand ne Ahnung, oder ne Idee?
jep. probier mal:
#include stdio.h
#include stdlib.h
int main()
{
void *buf = malloc ( (size_t) (30u) ); // genau 3 GB
if (buf==0) printf(oh no\n); else printf(yeah\n);
return 0;
};
du musst denke ich deinen algorithmus gruendlich ueberdenken und mittels
zwischenspeichern auf festplatte
den speicherbedarf __drastisch__ reduzieren.
das daemliche unix 32-bit design in verbindung mit der diesbezueglich ziemlich
daemlichen Sprache C
erbringt uns derzeit das naechste grosse problem der art wie sie schon so oft da war.
man denke nur
an das alte MS-DOS mit expanded memory, extended memory, hi memory area, 64kb offset
size und 16bit pointer
sowie dem pseudo 32bit pseudo seg+offs pointermist.
erste auslaeufer sind erkennbar mit den sogenannten large-files. sie koennen groesser
als 2GB sein.
man muss seine programme entsprechend umprogrammieren, damit sie mit solchen dateien
umgehen koennen.
der naechste mist ist schon vorprogrammiert. bei 128bit maschinen gibt es dann
large-large files.
besonders sinnvolle namensgebung uebrigens.
MfG
Erik
--
Erik Thiele
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian
Re: integer groesser 2^31 in C
On Mon, 30 Jun 2003 11:34:57 +0200 (CEST) Achim Fritz [EMAIL PROTECTED] wrote: On Mon, 30 Jun 2003, Erik Thiele wrote: On Sun, 29 Jun 2003 17:11:42 +0200 (CEST) Achim Fritz [EMAIL PROTECTED] wrote: Hallo Erik, erstmal danke fuer Deine ausfuehrliche Beschreibung. leider funktioniert es nicht: oh no (mit 20u gehts) Noch ne Idee? ganz spontan: jeder prozess kann in linux nur 2 gb memory haben. :-) ist dein algorithmus wirklich nicht aufteilbar, brauchst du wirklich die 4 GB gleichzeitig im RAM? MfG Erik -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
emacs ispell deutsch
Hallo, ich benutze Emacs und würde gerne flyspell verwenden. ich habe noch keine eigene emacs configuration und die liste der installierten pakete ist wie folgt: [EMAIL PROTECTED]:~$ dpkg -l *emacs*|grep ^i ii emacs2121.2-1 The GNU Emacs editor. ii emacsen-common 1.4.15 Common facilities for all emacsen. ii octave2.1-emac 2.1.35-7woody1 Emacs support for the GNU Octave language (2 [EMAIL PROTECTED]:~$ dpkg -l *spell*|grep ^i ii aspell 0.33.7.1-8 A more intelligent replacement for the ispel ii aspell-de 0.1-3-3German dictionary for aspell ii aspell-doc 0.33.7.1-8 Documentation about the aspell spell checker ii ispell 3.1.20-21.1International Ispell (an interactive spellin ii libaspell100.33.7.1-8 The aspell spell checker runtime libraries. ii libpspell4 0.12.2-5 Portable spell checker interface library ii openoffice.org 20020701-3 German spellchecking for OpenOffice.org (Ger [EMAIL PROTECTED]:~$ dpkg -l *germ*|grep ^i ii ingerman 20010414-0.1 New German orthography dictionary for ispell ii wngerman 20010414-0.1 New German orthography dictionary for /usr/s [EMAIL PROTECTED]:~$ aspell funktioniert wunderbar auf der console, aber flyspell möchte einfach nicht gescheit funktionieren. ich editiere meinen latex text und mache M-x flyspell-mode, dann M-x flyspell-buffer. Danach ist alles rot und gelb, er verwendet ein englisches Wörterbuch obwohl ich keines installiert habe? also mache ich im Emacs menü: tools - spell checking - change dictionary, und bekomme eine riessige liste von dictionaries die ich aber alle nicht installiert habe. Ich wähle deutsch8 aus, doch dann sagt er einfach can't check region. ich versuche ispell im emacs manuell zu machen, ohne flyspell. also M-x ispell-change-dictionary. wieder die liste nicht existierender dictionaries. ich wähle deutsch und er sagt mir er koenne /usr/lib/ispell/deutsch.hash nicht öffnen. also kucke ich was in dem verzeichnis alles drin ist. ich finde ndeutsch.hash. also moechte ich ndeutsch eingeben im emacs, aber dann sagt er [no match] und lässt es mich nicht auswählen. please help... cu erik -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Matrox Dual Head on Debian 3.0
On Wed, 19 Feb 2003 07:24:07 +0100 Erik Thiele [EMAIL PROTECTED] wrote: danke für eure Tipps! ich habe es endlich geschafft. ich wusste nicht, dass man von matrox treiber holen muss. ich dachte das sei bei xfree dabei. der mgapdesk erzeugt leicht buggy config files... der xserver stürzt dann sofort mit segmentation fault ab (4.2.0) nach längerem herumprobieren hab ich es aber doch hinbekommen. das X zeug ist und bleibt halt ein problem :-) cu thx again erik lspci sagt: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85) -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Matrox Dual Head on Debian 3.0
hi. ich benutze eine standard debian 3.0 lspci sagt: 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85) lspci -n sagt: 01:00.0 Class 0300: 102b:0525 (rev 85) ich dachte es sei eine G450 oder G550 oder so etwas in der art. jedenfalls dual head. ich kriege das X zeug nicht installiert. auf der karte ist gedruckt: matrox G45FMDHA32DB 971-0302 Rev:A kann ich irgendwie eine neuere X server version in mein system einbauen, ohne deshalb alles auf unstable zu upgraden? ich möchte einmal versuchen, ob die neueren Xserver das Teil unterstützen. Mfg, Erik -- Erik Thiele -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
