MIKEKT: 169.254.X.X ? Tak to nemá dostupný DHCP. Zkus ten full duplex nastavit napevno a dej vědět.

IMOLOL: jo tam je nejaka divna IP jako kdyz by nedostal normalni od routeru. Zkusim a hodim.

MIKEKT: kdyby to nefungovalo, pastni sem výpis ipconfig /all (stačí pro ten jeden adaptér) potom, co ho vzbudíš a nejde připojení.

MORTAELTH: zkousel jsem renew, ale zkusim posloupnoust tvych prikazu :)

IMOLOL: jo nejaky nastaveni napajeni jsem u te sitovky taky zkousel, ale bez vysledku. ten full duplex jeste zkusim.

Díky

MIKEKT: duvod me nenapada, ale zkus ipconfig /release => ipconfig /renew, nebo ipconfig /flushdns

IMOLOL: jo DHPC je. Po restartu to normlane prideli IP. Je tam nejaky obyc TPlink router myslim.

MIKEKT: a to DHCP je/není (předpokládám, že je). K jakýmu routeru/switchi je to pecko připojený?

IMOLOL: kdyz ten pocitac restartuju tak uz to bezi v pohode. Kabel jsem zkousel vyndat a zandat a nepomohlo.

mně něco podobnýho dělá wifina na jedné konkrétní wifi síti v kanclu ... když uspím počítač a pak probudím, tak musím ručně odpojit a znovu připojit tu wifi, aby to fungovalo ... když mezitím ten počítač probudím na jiné wifi, uspím, vrátím se do kanclu, tak se to chytne bez problémů hned ... na jiné wifině (doma, v kavárnách, v restauracích, u známých,...) mi to nedělá ... jenom tahle konkrétní v kanclu :-/

MIKEKT: dva dotazy - dostává IP z DHCP? a - zkoušel jsi po probuzení ze spánku vyndat/zandat síťovej kabel?

Ahoj, mam dotaz. resim problem s jednim PC s win10, ktery se po probuzeni ze spanku nepripoji na lan sit. Zkousel jsem ruzny navody na nastaveni spotreby v napajeni atd. Kdyz se da opravit sitove pripojeni tak to napise tohle "v počítači chybí jeden nebo více síťových protokolů" . Nesetkal jste se s tim nekdo? Je tam Gigabyte deska s intel sitovkou na desce.
Díky

Zdravím bando, noví majitelé se nám chystají ve firmě nainstalovat snowclient 3.7 a jakýsi active direktory export, mám se obávat nějakého špehování? Něco jsem se na netu dočetl o software auditu a snižování nákladů, ale radši se zeptám. Díky za odpověď.

ARIAEL:
přesně. db je na poli nikam se nehýbe. když se připojim na server a spustim skrz aplikaci úlohu tak ty samý sety dotazů trvaj o 5s méně jen tím že jsem je spustil přímo na serveru (proti produkci a během provozu samozřejmě).

udělali jsme si několik schémat abychom vyloučili že se trefíme do "dobrých" nebo cachovaných dotazů ale všude to vychází stejně.

odbc by tam nemělo hrát roli.

RAINBOF: Hm to ze jsi premistil DB z lokalu na pole by nemelo mit jiny vliv nez response samotneho data file. Tedy jestli dobre chapu ze jsi DB engine nechal tam kde predtim a nejde o DB pripojenou pres string ci pres nejaky ODBC...
Mimochodem jakym zpusobem pripojujes to pole?

ARIAEL: jenze ramka a indexy by se chovaly stejne i na lokálu. db v ram nedrží ani náhodou. jsou toho radove tb. jenže ono se nudi i to diskový pole tím provozem.

RAINBOF: Neresil, ale po pravde pripojuju disky pouze SAN kartama a SQL by jsem zase nedaval na vmware (at uz kvuli penezum ci cokoliv jinyho).
Mas dost pameti na to udrzet databazi v RAM? A to na co se ptas ma v poradku indexy?

Jumbo je takovy - no nevim. Taky ho nezapinam. Dulezita je mnohem vic rychlost odezvy nez prenaseni velkych packetu.

Ale mozna neco podobnyho jsme ted resili pro F5, kde kdyz jsme dali za balancer cokoliv co bezelo s domenou tak se komunikace s DC uplne rozpadla. Ani podrobne rozebirani veskere komunikace nevedlo k zadnym zaverum.
Dodavatel tvrdi ze F5 pracuje jak ma a vse prenasi. Ale kdyz se tam da domena tak bye bye...

RAINBOF: tcpdump?

ja myslim ze na to kaslem. mame svy pohledy a vime o nich. dal bych si tu nepomeroval parametry ani marketing (pohadejme se na toto tema jinde kde se managerovanim zabyvaj mozna tam prozreme vsichni).

nahodim jednu ducharskou zase ze sveta virtualizovanyho ms sql 2012 std :)
mam sql server na raidu 6 kterej jsem zvolil po benchmarku vykonu (vic se vyplati mit pole vkuse pomalejsi nez ho diky poctu disku porcovat na dve pole)
ted ta ducharina. kdyz je server v zatezi trva jista soustava dotazu cca 7.2ms ale lokalne ve stejnou dobu jen 2.1 kdyz je server bez zateze trva pod 900ms.
podezrivam vmware (esxi 6) ze to brzdi sitovka jen nevim jak to overit maximalni tok je 50mb pri plnym knedliku
rikal jsem si ze za to muze team sitovek ale ne. chova se to stejne. na tom serveru je 8 jader xeon e3 ale pouzivam aktualne jen 4 coz ale stavi stejnak se tam nic nedeje. virtual je jen jeden a os spravuje 50gb pameti z toho sql server pozral 45gb (nechal jsem si rezervu i ve vmware).


v dobe toho dotazu jsme z profilera a posloupnosti dotazu a jejich vykonani zjistili ze opravdu se na "neco" cekalo 5s je to nakupeni typu 400ms tu 500ms tamhle pak prolitne xx insertu jako blesk.
ve spicce je tam 150 dotazu/s takze nuda. k paralelizaci dojde malokdy. db je navrzena tak ze vyssi paralelni beh vpohode snese bez deadlocku nicmene stejne to neni treba takze jedu na default hodnotach max degree of paralelism a witing time.


nemate poneti co muze neco takoveho zpusobovat ? zda se ze tem 500ms predchazi insert v jiny sade dotazu kterej ale sam o sobe ale trva jednotky az desitky ms.

ja podezrivam sitovku na tom vmware kde pouzivam tu jejich paravirtual vmxnet bez jumbo paketu (nechodi mi to dobre)