Střípky z IT - (1). : Uhádnete, kde byl problém? (diskuse)

[p]

V lokalitě A sjížděj youtube?

[Max]

To by trochu odporovalo tomu, co jsem uvedl :
"Linky nejsou využity, takže i když IS zlobí, jede kopírování dat na konkrétní PC z pobočky do pobočky 600KiB/s úplně bez problémů. "
Takže ne.
Zdar Max

[Max]

Jinak internet mají převážně blokován a kdo ne, jede přes proxy, která provoz filtruje.
Zdar Max

[Rezza]

Internet blokovaný a cenzurovaný, takže ta lokace je v Číně a z toho ta prodleva!

[Max]

Tvé vtipné připomínky mají mezery :). Kdyby to tak bylo, tak ostatní komunikace po lajně by nebyla ok, tzn. GTS by sdělila, že má linka velké odezvy, nebo je přetížená atd., také by asi nejela linka plnou rychlostí při kopírování souborů mezi pobočkama, jak jsem zmínil, apod.
Zdar Max

[smoofy]

Prijde mi to jako problem domain serveru. Zrejme spatne resolvovani pro "192.168.2.0".

[Max]

To mně také napadlo, ale není to tak, dělalo to i v případě připojení čistě přes IP. Chyba v resolvování nebyla.
Zdar Max
PS:v onom sniffu je naznačeno, kde by mohl být skutečný problém

[rubicon]

Tomu nenasvědčuje ten snoop - nevidím tam příslušné časové mezery. Vzhledem k řadě "TCP segment of a reassembled PDU" bych hledal problém v nastavení max packet size u Oracle. Tzn., poladil bych tnsnames nějakým tím SDU=....

[Max]

Mno, to už vypadá na lepší tip, ale řešení to není. Chybka je ještě trochu někde jinde.
Zdar Max

[smoofy]

Na neco podobneho jsem take myslel, ale na strane klienta nebo serveru? Vzhledem k tomu, ze pripojeni k db ve druhe lokaci funguje v poradku tak klientto zrejme nebude a db server je z druhe lokace dostupny bez problemu. Ze by byla rozdilna nastaveni pro jednotlive lokace? To mi uz prijde pravdepodobnejsi problem s MTU na Cisco nebo neco takoveho.

[Michal Kubeček]

Pokud by někdo opravdu chtěl, abych problém řešil, tak bych po něm především chtěl kompletní capture file, ne jen vybraná pole, a samozřejmě pro srovnání i komunikaci L-B. A samozřejmě i informaci o tom, odkud přesně ten trace pochází.

Takhle jen takový nástřel: podezřele často se tam vyskytují zdánlivě bezdůvodné prodlevy 200 ms (u klienta) resp. 300 ms (u serveru), což by mohlo odpovídat timeoutu pro první retransmisi TCP paketu (linuxový default je HZ/5, tj. 200 ms), ale z nekompletní informace se mi nechce dopočítávat, jestli tam opravdu jsou retransmise nebo ne. Takže: neztrácejí se tam přeci jen někde pakety?

[Max]

Pravdu díš, packety se tam ztrácely. Po tom, co jsem viděl dump komunikace jsem nechal GTS prověřovat lajnu, už jsem neřešil porovnávání komunikace s jinou pobočkou, protože to ukazovalo celkem jasně na problém s lokalitou "L".
Měl jsem tedy stejné informace jako jsem zmínil v blogu.
Řešení jsem doplnil do blogu.
Zdar Max

[Michal Kubeček]

Mimochodem, chtělo by to použít tu značku zajišťující, aby se pole s výpisem objevilo až pod pravým sloupcem, takhle jsem si jeho obsah musel zkopírovat do editoru, aby to šlo číst.

[Max]

Hmm, to je tím rozlišením, co používám a nemyslím na lidi s menším rozlišením, už mi to ani nepřijde. Mám 24" monitor a tak většinou nemám s ničím problém, to samé v práci (všechna kancelářská PC mají 24" monitor).
Zdar Max
PS:na tu značku se podívám

[Michal Kubeček]

Což o to, já mám 27" s rozlišením 2560x1440 - ale prohlížeč pochopitelně není přes celou šířku.

[mess]

Já bych to tipnul na nějaký problém s routingem - třeba že cesta L->A má nějakou blbou náhodou stejnou metriku jako L->B->A (případně naopak A->L a A->B->L) a ty Cisco routery se snaží udělat něco jako load balancing mezi těma linkama. A firewall ty odpovědi, které přijdou zpátky na jiné rozhraní, než ze kterého odešel požadavek, zahodí.

A ve spojení s (třeba) opakovaným odesíláním požadavku/odpovědí se to "nějak" vykryje, jenom to trvá. Na lince se samozřejmě pakety neztrácejí, problém je až na routeru, proto to v monitoringu od GTS není vidět. Na sniffu PC to taky být vidět nemusí, pokud požadavek odejde v pohodě a odpověď taky nakonec nějak dorazí.

[Max]

Jelikož "Michal Kubeček" na to kápnul, tak jsem doplnil řešení do blogu.
Zdar Max

[bigBRAMBOR]

Oracle v A bezi na WIN a v B na Lin, proto na B nema vliv chyba mezi switchem a routerem v L, ale na A vliv má? No, zní to jako pěkná blbost.

[Max]

Špatně to chápeš, řekl bych spíše, že se chyba vzniklá duplex mishmatch na spoji do lokace "B" tolik neprojevuje, nebo se tolik neprojevuje na komunikaci IS s Oraclem. To může být způsobeno rozdílnou komunikací (jednak rozdílné verze Oracle, ale i operačních systémů). Je třeba možné, že Oracle 11 je více vlídnější ke komunikaci po ztrátových linkách oproti Oracle 10 v lokaci "A". Podmínky prostě nejsou stejné pro obě lokace a tak nemusí být problém v lokaci "B" na první pohled patrný.
Zdar Max

[bigBRAMBOR]

ja to chapu velmi dobre, ale priznejme si ze udelat zapis jako hadanku, nazvat to střípky z IT - kdo uhadne kde byla chyba, pricemz reseni je spatnej switch, ale to se projevuje jenom na jedne lajne, ale na druhe ne, a mozna to je zpusobene rozdilnou verzi Oracle - verzi jsi puvodne nenapsal, nebo rozdilnou verzí OS, to jsi napsal, to neni ani střípek z IT, ani hádanka, to je prostě duchařina. Hádance dávám za 5. A to čistou.

[vencour]

Malý postřehy z praxe: pingat velké pakety (klidně desítky kB), postupovat krok za krokem. Občas je požadováno specifické nastavení portu, občas chodí auto a občas nastavení natvrdo.
Mimochodem v linuxu funguje např. "ethtool -s eth0", u serverů by něco takového mohlo taky být k mání?