Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - scientific

Stran: 1 ... 7 8 [9] 10 11 ... 17
121
Hardware / Re:Server občas přestane komunikovat
« kdy: 08. 03. 2020, 20:26:29 »
LA_user: Kdy klávesnice přestala fungovat já nevím, ale dá se předpokládat z výše uvedeného logu, že v 9:41 okolo této doby jsou pouze výše uvedené logy + CRON log, jde je pouze zaznamenáno, že byla spuštěna rutina spouštěná po minutě. Logy nám tedy již nic dalšího neřeknou.

Filip Jirsák: Za magické tlačítko moc děkuji, snad bude fungovat, až ho budu potřebovat. Nicméně, je divné, že se během tohoto záseku zasekne i samotný systém, protože je díra i v /var/log/messages, viz výše. Z toho důvodu se jako amatér domnívám, že nebude na magickou klávesu reagovat. Zařízením je korporátní počítač Dell OptiPlex SFF 7010,  bez použití speciálních ovladačů, běží na už pár měsíců pořád stejné služby a tento problém se mi začal stávat až v poslední době. Mám pocit, že s magické zkratky mi hodně pomohou, zkusím to, děkuji moc.

122
Hardware / Re:Server občas přestane komunikovat
« kdy: 08. 03. 2020, 17:40:18 »
Během té doby co nereagoval, tak vůbec v logách nic není, Zřejmě cca. v 9:41 nějak zamrznul a 9:49 sem si toho všiml a podržel sem power button, dokud se na tvrdo nechcípnul a hned v 09:49 logy navázali, protože se tentokrát nepodělal XFS.

Kód: [Vybrat]
Mar  8 09:31:05 Dell-Optiplex7010 systemd[1]: Started Session 12696 of user root.
Mar  8 09:31:06 Dell-Optiplex7010 systemd[1]: Started Session 12697 of user root.
Mar  8 09:32:05 Dell-Optiplex7010 systemd[1]: Started Session 12698 of user root.
Mar  8 09:32:05 Dell-Optiplex7010 systemd[1]: Started Session 12699 of user root.
Mar  8 09:33:03 Dell-Optiplex7010 systemd[1]: Started Session 12700 of user root.
Mar  8 09:33:03 Dell-Optiplex7010 systemd[1]: Started Session 12701 of user root.
Mar  8 09:34:02 Dell-Optiplex7010 systemd[1]: Started Session 12703 of user root.
Mar  8 09:34:02 Dell-Optiplex7010 systemd[1]: Started Session 12702 of user root.
Mar  8 09:35:01 Dell-Optiplex7010 systemd[1]: Started Session 12705 of user root.
Mar  8 09:35:01 Dell-Optiplex7010 systemd[1]: Started Session 12704 of user root.
Mar  8 09:36:02 Dell-Optiplex7010 systemd[1]: Started Session 12707 of user root.
Mar  8 09:36:02 Dell-Optiplex7010 systemd[1]: Started Session 12706 of user root.
Mar  8 09:37:04 Dell-Optiplex7010 systemd[1]: Started Session 12709 of user root.
Mar  8 09:37:04 Dell-Optiplex7010 systemd[1]: Started Session 12708 of user root.
Mar  8 09:38:01 Dell-Optiplex7010 systemd[1]: Started Session 12711 of user root.
Mar  8 09:38:01 Dell-Optiplex7010 systemd[1]: Started Session 12710 of user root.
Mar  8 09:39:02 Dell-Optiplex7010 systemd[1]: Started Session 12712 of user root.
Mar  8 09:39:02 Dell-Optiplex7010 systemd[1]: Started Session 12713 of user root.
Mar  8 09:40:04 Dell-Optiplex7010 systemd[1]: Started Session 12715 of user root.
Mar  8 09:40:06 Dell-Optiplex7010 systemd[1]: Started Session 12714 of user root.
Mar  8 09:41:02 Dell-Optiplex7010 systemd[1]: Started Session 12716 of user root.
Mar  8 09:41:02 Dell-Optiplex7010 systemd[1]: Started Session 12717 of user root.
Mar  8 09:49:45 Dell-Optiplex7010 kernel: Linux version 4.18.0-80.11.2.el8_0.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 8.2.1 20180905 (Red Hat 8.2.1-3) (GCC)) #1 SMP Tue Sep 24 11:32:19 UTC 2019
Mar  8 09:49:45 Dell-Optiplex7010 kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-80.11.2.el8_0.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet

123
Hardware / Re:Server občas přestane komunikovat
« kdy: 08. 03. 2020, 12:14:38 »
Zřejmě tedy integrovanou. Ještě dodám důležitou informaci, že jsem vypozoroval, že v ten čas to vždy indikátor (nevím jistě čeho) svítí trvale, viz foto.

Teď přestože s monitorem komunikuje, tak chvílema nereaguje na klávesnici a myš. Přestože load je obvykle mezi 1.0 a 4.0, což je hádám přijatelné, průměrné využití CPU je 20 % nárazově 80 %, 32 bitový systém RAM není problém a IO max 1mbps.

[root@Dell-Optiplex7010 firefox]# lshw -C display
  *-display                 
       description: VGA compatible controller
       product: Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:27 memory:f7800000-f7bfffff memory:e0000000-efffffff ioport:f000(size=64) memory:c0000-dffff

[root@Dell-Optiplex7010 firefox]# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family   : 6
model      : 58
model name   : Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
stepping   : 9
microcode   : 0x21
cpu MHz      : 3201.646
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 0
cpu cores   : 2
apicid      : 0
initial apicid   : 0
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln pts md_clear flush_l1d
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips   : 6784.31
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family   : 6
model      : 58
model name   : Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
stepping   : 9
microcode   : 0x21
cpu MHz      : 3384.745
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 1
cpu cores   : 2
apicid      : 2
initial apicid   : 2
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln pts md_clear flush_l1d
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips   : 6784.31
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family   : 6
model      : 58
model name   : Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
stepping   : 9
microcode   : 0x21
cpu MHz      : 2462.515
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 0
cpu cores   : 2
apicid      : 1
initial apicid   : 1
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln pts md_clear flush_l1d
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips   : 6784.31
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family   : 6
model      : 58
model name   : Intel(R) Core(TM) i3-3240 CPU @ 3.40GHz
stepping   : 9
microcode   : 0x21
cpu MHz      : 2982.469
cache size   : 3072 KB
physical id   : 0
siblings   : 4
core id      : 1
cpu cores   : 2
apicid      : 3
initial apicid   : 3
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx f16c lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm arat pln pts md_clear flush_l1d
bugs      : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
bogomips   : 6784.31
clflush size   : 64
cache_alignment   : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[root@Dell-Optiplex7010 firefox]#


124
Hardware / Server občas přestane komunikovat
« kdy: 08. 03. 2020, 10:49:04 »
Ahoj všem, prosím o radu, mám PC s CentOS jako homeserver. Začalo se mi ale stávat to, že se mi po několika dnech od spuštění nedaří probudit monitor (stisknutím libovolné klávesnice ani jinak) , ten píše "no signal".

Další zvláštnost je taková, že při běžném stavu se dá krátce stiknout power button a PC se uspí, dalším kliknutím se zase probudí. V popsaném případě, kdy PC s monitorem nekomunikuje (přestože běží) krátké stiknutí power button nefunguje a je nutné tlačítko podržet dokud se na tvrdo nevypne, čímž tak jednou z 5 pokusů zničím XFS.

Prosím, jak to diagnostikovat? Děkuji za tipy.

125
Software / Re:Zřejmě poškozený FS po výpadku elektřiny?
« kdy: 06. 02. 2020, 21:21:56 »
smazano

126
Server / Re:Jak zjistit reálný výkon CPU u VPS?
« kdy: 30. 01. 2020, 19:23:23 »
To není pravda, protože při aplikování CPU profilu na omezení 1 % CPU hostitelského serveru se v TOP hostitelského serveru snížilo při benchmarku využití CPU VPS 1x vCPU ze stabilních 100 % na  stabilních 38 %.

Co se týká cat /proc/cpuinfo, tak tam najdu informace o hostitelském procesoru, ale to nemá žádnou vypovídající hodnotu o možnostech VPS přístupu k fyzickému CPU.

127
Server / Re:Jak zjistit reálný výkon CPU u VPS?
« kdy: 30. 01. 2020, 10:17:14 »
Stress a sysbench jsem zkusil, ale nezdá se mi, že by to umělo co potřebuji. Umí to akorát zatížit CPU, což mi je jako takové k ničemu. Nebo to neumím používat?

Potřebuji: Zjistit reálný výkon CPU, tedy kolik má k dispozici vláken, a do jaké míry je může využívat. Zjistit, co to se serverem udělalo /jak ho to omezilo), když nastavím CPU profil třeba na 40 %.

Věděl byste někdo prosím, jak toho docílit?


128
Server / Re:Jak zjistit reálný výkon CPU u VPS?
« kdy: 30. 01. 2020, 08:09:07 »
Ostatní limity pro traffic/IO/RAM řeším taky, ale teď řeším vyloženě CPU, protože to jediné neumím otestovat.

Akorát jdu zkust ten stress a sysbech, co jste doporučovali.

129
Server / Re:Jak zjistit reálný výkon CPU u VPS?
« kdy: 29. 01. 2020, 18:44:48 »
@ Ondřej Kolín: Už jsem o tom četl, zkusím to. Děkuji za tip.

@ Ondrej Nemecek: Myslím, že tenhle myslím, že jsem použil a byl to přesně případ o kterém jsem psal v závěru. Mrknu na to. Že to musím ověřit vím, proto jsem založil toto téma. Zkusím od toho člověka dohledat nějaké
informace.

@cek_post.cz: Je tam 32 logických online jader, ale uvažujme ve výpočtu 2x8 fyzických jader (bez HT). Neumím ověřit jak se ten výpočet počítá, proto se ptám jak to měřit, abych ověřil, zda 3 % jsou OK či nikoliv. A nějakou rezervu není cílem, aby jedno VPS permanentně mělo CPU na 90 %. Nárazově to hádám asi chvilku nebude stíhat a odezva bude pomalejší, ale po chvilce by load toho VPS měl klesnout, až to přechroupe. Když budu mít 10x VPU (po 4x vCPU) a každé z nich bude mít limit 40 procent fyzického CPU, znamenalo by to, že když by 2 z 10 VPS bylo na 90 %, tak by docházelo k přetížení hosta, protože by jen ty dva servery udělali 80 % zatížení fyzického serveu a nedejbože kdyby byly další servery o něco více zatíženy. Nepředpokládám, že "všechny" servery budou na krev, ale minimálně dva z nich určitě ano.

@Všichni: Teorii už asi vím, možná si trochu připouštím, že tenhle limit bych zavádět neměl a kdyby jo, tak třeba v poměru 10 % na každé vCPU, ne pouze 3 %.

Zkusím ten stress + mrknu na ten sysbench a snad mi něco z toho pomůže  ověřit nastavení limitu a najít jeho ideální nastavení.

130
Server / Jak zjistit reálný výkon CPU u VPS?
« kdy: 29. 01. 2020, 13:11:26 »
Ahoj všem,

prosím si o radu, pokusím se být stručný.

Cíl
Omezit CPU profilem jednotlivé VPS tak, aby při přetížení libovolného VPS nedocházelo k přetížení hostujícího fyzického serveru. Přičemž CPU profil umožňuje nastavit limit vCPU VPS pro využívání CPU fyzického serveru (např VPS1 smí využívat při uvažované utilizaci maximálně 12 % celkového výkonu fyzického CPU).

Co jsem zkusil
  • Vypočítal jsem si dle fyzického CPU, že na každou jednu vCPU připadá cca. 3 % CPU fyzického serveru.
  • Nasadil jsem profil 12 % CPU na VPS 4x vCPU.
  • A pozoroval jak unlimited server je podstatně rychlejší, než ten s aplikovaným CPU profilem s limitem 12 % CPU.

Potřebuji poradit
Jak ověřit, zda mnou vypočítaná hodnota 3 % je správná. Jak ověřit v jaké míře je VPS při konfiguraci 4x vCPU schopný využívat fyzicky CPU.


Všechny bechmarky co jsem našel fungují stylem, že zatěžují pomocí dd I/O spíš než CPU (jako třeba tar) a počítají za jak dlouho se příkaz dokončí. Já bych potřeboval spíše dokázat měřit, jak simulovat, kolika vlákny umí VPS komunikovat.

Děkuji všem zkušenějším za rady.

131
Dobře, děkuji ti moc. :-)
Na bugzillu sem jim to přidal, tak uvidíme, či to dají do kupy.

132
Software / Re:Firefox - Problém s proxy (možná cache)
« kdy: 25. 01. 2020, 15:24:06 »
Ty jsi génius. Jsem moc rád, že se na celém foru našel alespoň jeden člověk co olihni rozumí a má chuť mi pomoci.  Díky ti moc, já amatér bych se s tím zlobil tak dlouho, až bych to vzdal. :-) Karma +1000000000000 tobě. :-)


133
Ještě doposílám požadované informace:

network.automatic-ntlm-auth.allow-proxies   true   
network.negotiate-auth.allow-proxies   true

Už jsem to také hodiny googlil, možná jsem to změnil na true já na základě nějakého doporučení odněkud.

Mám pocit, že odkazy, které jsi mi poslal se mě netýkají, tam se tazatelé ptají, naopak, proč se jich firefox neptá na přihlašovací http autentizační okno. Já to mám naopak, já bych chtěl, aby se mě neptal. Nebo jsem jen špatně porozuměl překladu.


134
Ještě znovu shrnu o co mi jde:

S každým spuštěním Firefoxu po mě Firefox vyžaduje přihlášení k proxy prostřednictvím http autentizačního okna, i přesto, že vždycky zaškrtávám "uložit přihlašovací údaje". Viz screenshot, co se mi objevuje s každým zapnutím prohlížeče.

Očekával bych, že se přihlásím jednou a pak už o tomhle okně nikdy neuslyším.

Chápu tě tak, že s tím máš zkušenost a funguje ti to správně, že ses přihlásil před rokem jednou, heslo si uložil a máš klid?

V tom případě nechápu, co dělám špatně. Jelikož jsi profík na proxy, nevidíš tam náhodou souvislost s tím druhým problémem proxy serveru, který řešíme? Či souvislost s jinou konfigurací proxy serveru? Zkusím to ještě otestovat z jiného zařízení, třeba tím vyloučím chybu na straně mého Firefoxu.




135
Software / Re:Firefox - Problém s proxy (možná cache)
« kdy: 25. 01. 2020, 10:58:21 »
To by to ale přece nefungovalo ani tady, kde to funguje, při různých adresách (aliasech toho stejného webu, kde to nejde):

Curl z CLI vrátilo ve pokaždé jinou správnou adresu vždy SPRÁVNĚ:

   
Kód: [Vybrat]
curl --proxy http://user1:pass1@proxy_ip:3128 http://user1.mujweb.cz/mojeip-z-headeru.cz
    Vrací: 111.111.111.111
curl --proxy http://user2:pass2@proxy_ip:3128 http://user2.mujweb.cz/mojeip-z-headeru.cz
    Vrací: 222.222.222.222
curl --proxy http://user3:pass3@proxy_ip:3128 http://user3.mujweb.cz/mojeip-z-headeru.cz
    Vrací: 333.333.333.333

Stran: 1 ... 7 8 [9] 10 11 ... 17