Uutiset:

Ei uusia uutisia.

Main Menu

EWN sivusto

Aloittaja weatherc, lauantai, 22.12.2018, 14:21

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

weatherc

Tuli Digitrafficilta vastaus siihen tiesäiden sateiden nollaukseen heidän Google-ryhmässä (joka myös heidän supportkanava).
Eipäs ollutkaan kunnossapidollisista syistä kuten einari arvasi...

Lainaa
Kiitos mielenkiintoisesta kysymyksestä.  Kysyin tätä lähdejärjestelmän suunnasta ja tässä on kuulemma historian painolastia mukana.  Meteorologiassa tuo kello 06 (ilmeisesti Suomen lokaaliaikaa) on aika jolloin sademittarit on joskus muinoin ihmisten toimesta mitattu ja tyhjennetty.  Käytäntöä ei ole sitten muutettu tekniikan kehittyessä

einari

Lainaus käyttäjältä: weatherc - torstai, 09.01.2020, 11:21
Tuli Digitrafficilta vastaus siihen tiesäiden sateiden nollaukseen heidän Google-ryhmässä (joka myös heidän supportkanava).
Eipäs ollutkaan kunnossapidollisista syistä kuten einari arvasi...

Se on hyvä kun joskus arvaukset menee pieleen. 8)
(se kyllä perustui tiemestarin sanomisiin... )

Mitenköhän tuo heitin tekniikkansa ottaa huomioon sen ettei niitä ne ihmiset justiin kuuden aikaan tyhjäilleet... huonona päivänä saattanut mennä iltaan :D

Laitoin 20 napsua sademittariin... kertyi 0,9 mm... saa taas seurata missä mennään...vieläkö metsässä.. ???

weatherc

Lainaus käyttäjältä: einari - torstai, 09.01.2020, 12:08
Laitoin 20 napsua sademittariin... kertyi 0,9 mm... saa taas seurata missä mennään...vieläkö metsässä.. ???

Katso myös että lisääkö EWN tuon 0.9 mm sinne kk ja vuosisateeseen puolitaöin (jos itse unhodan katsoa sitä)  ;)

einari

Lainaus käyttäjältä: weatherc - torstai, 09.01.2020, 14:18
Katso myös että lisääkö EWN tuon 0.9 mm sinne kk ja vuosisateeseen puolitaöin (jos itse unhodan katsoa sitä)  ;)

Kuukausikäppyrään kyllä ilmaantui.. mutta muuten taas sai null-arvon noin 4 tunnin toiminnan jälkeen... saattaapi olla jokin Mungo Db- virhe..... jotain tuolllaista ehkä...?
    "If a document does not have a value for the indexed field in a unique index, the index will store a null value for this document. Because of the unique constraint, MongoDB will only permit one document that lacks the indexed field. If there is more than one document without a value for the indexed field or is missing the indexed field, the index build will fail with a duplicate key error.
    You can combine the unique constraint with the sparse index to filter these null values from the unique index and avoid the error.
unique indexes
    Sparse indexes only contain entries for documents that have the indexed field, even if the index field contains a null value."


Tällä erää saa unohtaa sen kk ja vuosisateen katselun :D

einari

Netatmo vastasi.. pitää laajentaa vähän niiden tietämystä uudella maililla... tapansa mukaan haluaa ensin tutkia minun asemani... ollos hyvä vain, tosin oli laittanut eteenpäin API-pomolle sen... :D

Tein juuri laskennan.. koordinaateilla lat_ne/lon_ne 64/25 ja lat_sw/lon_sw 62/22 >> tulos oli rain -haulla 97 asemaa joista 40 näytti oikein desimaalilukuna ja 57 oli null-arvolla... ei oikein nyt pelitä se oikein... tuo rain_24-juttu....  8)

Viittaisi kyllä vahvasti siihen Mongo-virheeseen...

heitin vastaus....

Thank you for contacting Netatmo Support.

Could you give me the serials numbers of the stations in question so that we can investigate?
In the meantime, I will transfer your request to our lead API Manager to handle your case as efficiently as possible.

Pitääpi kaivaa sarjanumerot ja mac-osoitteet niillle ja laittaa kuvankaappaus siitä hausta heille...


weatherc

Rehellisesti sanoen, kasa tumpeloitako tuota pyörittää Ranskan päässä, vai eikö heitä edes kiinnosta?  Ainakin tuo vastaus on kyllä niin "vakio-vastaus" kun olla ja voi. Kysellään jotain mac-numeroita vaikka vika ollut jo viikkoja ja luulis heillä olevan homma jo hyvin tiedossa ja työn alla, koska luultavasti noita null-asemia on muitakin...

einari

Lainaus käyttäjältä: weatherc - perjantai, 10.01.2020, 11:26
Rehellisesti sanoen, kasa tumpeloitako tuota pyörittää Ranskan päässä, vai eikö heitä edes kiinnosta?  Ainakin tuo vastaus on kyllä niin "vakio-vastaus" kun olla ja voi. Kysellään jotain mac-numeroita vaikka vika ollut jo viikkoja ja luulis heillä olevan homma jo hyvin tiedossa ja työn alla, koska luultavasti noita null-asemia on muitakin...

Tumpelo-sana jo toisen kerran.. tosin käytin keskiviikkona lisänä tuuraajia... 8)

Joskus aikoinaan kastselin hieman heidän hierarkiaansa.. eri tiimeistä koostuu ja vieläpä silloin eri firmojen.. nyt ne ilmeisesti ovat saman LeGrand-konsernin alla kaikki, poislukien tietenkin verkkopalvelut ja palvelimet jotka on siellä SAS-Onlinessa.. ilmeisesti kovin tehokasta ei tiedonsiirto ole eri tiimien välillä..

Tosiaan.. luulisi ongelman olevan jo niiden tiedossa, tai sitten kukaan ei ole valittanut..tuskimpa moni tässä laajuudessa getpublicdataa käyttää.. enempi niitä kolmansien osapuolien juttuja jolloin saavat asemakohtaista dataa... paitsi tietenkin YR. luulisi sen välittävän ja antaneen palautetta ;D

einari

Eilen pysyi ihan hyvin testisateet, 23.29 0li käppyrässä  (vanha) vielä sademäärä, 22.59 oli nollaantunut.. harmi kun sattui siihen kohtaan se "pakollinen" pitempi väli tuolla 12 min. kierrolla.. WU antoi 23.49 viimeisen ajan, samoin meteoware, joten siinä 23.49-23.59 nollaus tapahtui... pitäisikö se tehdä niin että se arvo jää voimaan joka on suurempi kuin 0 ?  8)
tai ainakin aikaistaa....

muistelen.. (enkä tarkista) että jossain mainitsit 23.55  viimeisen luennan ennen nollausta.. tuo eilinen ei ainakaan mahtunut siihen..  käppyrässä kyllä on.. :D

Käyn laittamassa taas tilkan sadetta kiposta... näkee että pysyykö tänään...

weatherc

Kuulostaa ok:lta :)
Tuo mainitsemani 23:55 oli vaan esimerkki, sillä vuorokauden viimeisellä päivitysajalla ei ole merkitystä koska se tarkistaa kannassa jo olevan datan ja päivityksen päivämäärät. Jos eroavat = nollaus sekä vanhan lukeman lisäys kk/vuosi-lukemaan ennen uuden päivittämistä. 

Met-asemien käyrätaulukko jotenkin jumissa. Ei tahdo oikeen onnistua mikään siinä. Datan lisäys ja lukeminen asema-tasolla näyttää onnistuvan mutta esim siivous ei. Tarkoitus olis siivota ulos vanhat datat siitä. Kokoa sillä phpmyadminin mukaan on reilut 55M riviä ja 8.4G. PWS-taulukko on 99M riviä...
Ongelma nuossa on se ettei InnoDB:n bufferpool:in optimaalinen koko enää mahdu RAM:iin kun koko kannan koko on vajaat 20G...Siivouksen yksi taka-ajatus on juuri se että sais piennettyä sitä niin että mahtusi taas. Nuo 2 käyrätaulukkoa kun ovat tyyliin 19G kannan 20G:stä...

weatherc

On toi mysli vekkuli epeli, sillä saa jopa palvelimen kyykkyyn jos haluaa ;D nimim. loadit pahimillaan yli 100  8)

Projekti käppyrätaulujen pienentäminen lähti käyntiin aika takkuisesti vaikka aloitin varoivaisesti eli tarkoitus siivota met-asemat ja datat ennen 2019-01-01 (päämäärä jättää maks pari kk datat). Tulos: Killed. Ja kun Inno kyseessä niin sehän palaa tuossa kohtaan takaisin alkupisteeseen eli tekee rollbackin. Kiitos prkleesti, ei pysty edes lirkuttamalla etenemään.
Google ja Stackoverflow antoi vastaukseksi tuohon Killediin että "muisti vähissä". Juu, sen tiesin kyllä ilman heitäkin. Ja koska muistit vähissä niin loaditkin huiteli aika taivaissa tuossa kohtaa, kyseessä kun on live-serveri joka tekee paljon muutakin...Pahimillaan loadit kävi mainitsemassani yli 100:ssa (4 (!!!) olisi "hyvän" raja) ollen kuitenkin suurin osa ajasta 10 ja 30 välimaastossa. Ja kyllä, mysli oli tuohon syypää, myslin uudelleenkäynnistys tiputti loadit oitis n 2:een.

Eikä muutama uusintayritys auttanut asiaa, sama tulos..

Yritys 2: Tehdään uusi taulu ja siihen kopiodaan halutut datat vanhasta. Eli uudemmat kuin 2019-10-31 päivätyt.
Kunhan maltto odottaa sellaiset 1.5h eikä hermostunut siitä että komentorivi nukahti (prosessi jäi käyntiin kun katseli "show processlist") niin jeps, palttirallaa 23M riviä kopioitu ja kokoa noin 4 GB (niin phpmyadmin tuossa kohtaa väitti). No onhan se puolet pienempi kun vanha.

Sama tehtiin pws-käyrille. Ja taas odoteltiin.
Tässä kohtaa väitti phpmyadmin koko kooksi n 8 GB. Woot.
Noh, ajetaan vielä taulujen optimointi "mysqlcheck -o --all-databases", fragmenteerattuja tauluja oli reippaasti yli 100, eli sitä ei oo "vähään aikaan" tehty.
Reilun tunnin raksutettua niin oho, nuo käppyrätaulut pieneni taas. Nyt molemmilla kokoa yhteentä 40M riviä ja reilut 4 GB. Noniin... 8)

Pitääpi virittää ajastus joka pitää noiden koot kuosissa...