New version of python-gammu has been just released. It fixes annoying problem with reporting wrong Gammu version and brings compatibility with Gammu 1.19.0. Full list of changes:
Download from usual place: http://cihar.com/gammu/python/
I just released version 0.26 of Wammu. This release fixes various problems found by users. Full list of changes:
There is still no working binary for Windows. I don't have time and environment for maintaining them. Volunteers are welcome!
One of reasons to setup my own Jabber server was to be able to store history on server while having data under my control. I use Jabber clients from several locations and having history on the server seems to be logical step.
Unfortunately implementations of XEP-0136 are a bit lacking. During install I enabled mod_archive, but it was not using up to date specification and there is no client which works with it, so there was no way to view data in it. Recently I found out that rewrite of this module exists - mod_archive_odbc. It is implementing current version of XEP-0136 and is using SQL database for storage (so at least writing SQL query to grab data is not that complicated as with Mnesia database used by original version).
Migrating of current history went quite good using wswutils, at least I did not notice any problems so far. The only problem is no support from clients. The only reliable way which works for now is Jabber archive web reader, but I'd really like to see integration in Gajim, any volunteers? :-)
New version of simple todo manager called Ukolovnik has been just released. There are no major changes in this release compared to 0.9, it mostly happened to indicate that this small piece of code has reached some level of stability and wanted level of features.
New Gammu testing version is out. This time release period is a bit longer than usual, mostly because my moving back to Prague. 1.18.91 again only fixes some bugs:
You can download from usual place: http://cihar.com/gammu/.
PS: Debian users can get packages from experimental.
Občas do databáze potřebujeme také nahrát data získaná v jiných programech. I pro tuto možnost phpMyAdmin nabízí podporu ve svém rozhraní, ale pokud budete potřebovat pracovat s většími objemy dat, je lepší použít některé nástroje pro příkazovou řádku.
Množství formátů pro import není ani zdaleka tak rozsáhlé jako u možností pro export – phpMyAdmin podporuje import jen pro CSV, SQL a DocSQL soubory. Stejně tak jako u exportu ale máte možnost si napsat vlastní modul pro práci s vaším souborovým formátem, rozhraní pro moduly je podobné jako u exportních modulů .
Protože zpracování dat dochází na straně web serveru a data jsou přenášena přes HTTP, může u velkých objemů dat dojít k vypršení různých časových limitů. Limit běhu PHP
(pokud to nastavení PHP umožňuje, například v safe mode to není možné) můžete nastavit pomocí proměnné
$cfg['ExecTimeLimit']
. Nastavením na nulu omezení doby času běhu
PHP odstraníme úplně. Nicméně pořád ještě může vypršet časový limit HTTP přenosu, který nemůžeme nijak ovlivnit.
Další omezení je velikost nahraného souboru. Toto upravují parametry
upload_max_filesize
a
post_max_size
v nastaveních PHP (soubor
php.ini
nebo
případně
.htaccess
s lokálním nastavením pro některé adresáře). Oba tyto parametry omezují maximální velikost souboru, který lze na server nahrát. Vše výše zmíněné
předpokládá povolení nahrávání souborů pomocí direktivy
file_uploads
.
Poslední omezení na které můžeme narazit je velikosti použité paměti. To je možné opět nastavit v phpMyAdminovi pomocí proměnné
$cfg['MemoryLimit']
.
Pokud přes phpMyAdmina potřebujeme pracovat s velkými soubory, máme přes popsaná omezení několik možností.
Nejpohodlnější je nahrát soubor na server jinou cestou a v phpMyAdminovi povolit načítání souborů pro import ze serveru:
$cfg['UploadDir'] = './upload';
Nyní nám phpMyAdmin nabídne na stránce pro import i soubory uložené v tomto adresáři a tímto se vyhneme problémům s HTTP přenosem. Ale pořád zůstávají omezení na spotřebovanou paměť a dobu běhu PHP.
Tyto omezení můžeme obejít částečným importováním souboru dokud ho nezpracujeme celý. Pokud je povolen částečný import phpMyAdmin se snaží předem detekovat situaci kdy by došlo k dosažení těchto limitů a pokud toto hrozí import se přeruší. Opětovným odesláním formuláře bude import pokračovat od poslední zpracované pozice. V případě že jsme soubor nahrávali přes HTTP musíme však soubor nahrát znovu.
Pro všechny formáty je možné vybrat znakovou sadu, ve které je soubor a phpMyAdmin automaticky rozezná případnou kompresi souborů (gzip, bzip2 a zip, ale záleží na tom co vaše PHP podporuje).
SQL export asi není třeba rozebírat, jen je možné nastavit režim kompatibility, v jakém se bude dotaz provávět.
Do jednotlivých tabulek je možné nahrávat data z CSV souborů (tento import tedy funguje jen pro jednotlivé tabulky a ne pro celou databázi). U CSV importu je možné nastavit řadu
parametrů určující jak je soubor formátován (oddělovače sloupců, řádků a podobně). Pokud to MySQL server povoluje, je možné také kromě parseru v phpMyAdminovi použít příkaz MySQL
LOAD DATA
. Tato volba je obvykle rychlejší, ale nenabízí tolik možností ovlivnění běhu a v některých konfiguracích MySQL serveru ji nelze použít.
Toto je dnes již poměrně historický formát pro popis tabulek a phpMyAdmin umí podle tohoto popisu tabulky vytvořit. Protože se jedná o vytváření tabulek, tento import je dostupný jen pro databázi.
For a long time I had problems on my work computers with Network manager still thinking that it is not connected. And I was really lazy to debug it. But as more and more application take online/offline settings from it, this became more and more annoying.
After some googling I found out that the problem might be in
/etc/network/interfaces file, which is parsed by Network manager. Some
"complex" things might confuse it. Well in my case the complex thing was
calling of some script in post-up. Commenting this out magically fixes
everything. Moving script to /etc/network/if-up.d/ also is not a big
problem, but why the hell the Network manager thing does not tell where
the problem is?
Před týdnem jsme se podívali na stránku zobrazující stav serveru, ale to zdaleka není jediná možnost jak se podívat co se na serveru děje.
Pokud je MySQL server hodně zatížen, může být snadné identifikovat viníka ze seznamu běžících dotazů . Pro každý dotaz zde vidíme jak dlouho běží, který uživatel ho spustil a můžeme ho také ukončit.
MySQL server uchovává historii dotazů, které nějak měnily (nebo mohly změnit) data na serveru. Tento log si můžete prohlédnout na stránce s binárními logy . Prohledávání tohoto seznamu však může být poměrně časově náročné.
Další zajímavou stránkou může být seznam podporovaných úložišť . Kromě jejich přehledu se zde po kliknutí na ně dozvíme i informace o jejich stavu a případně o proměnných ovlivňujících jejich chování. Nejvíce informací je v současné době dostupné pro InnoDB.
MySQL server v současné době podporuje mnoho znakových sad a pro většinu z nich i více možností porovnávání. Podrobnější informace na toto téma již přinesl článek o problémech s češtinou . Seznam znakových sad, které podporuje váš MySQL server, naleznete na samostatné stránce . Zvýrazněná porovnání jsou výchozí pro danou znakovou sadu.
Proměnné a nastavení serveru je poslední část kterou si dnes projdeme. Jsou na ní vypsány všechny proměnné MySQL serveru a jejich hodnoty. Pokud se nastavení aktuálního připojení liší od globálního nastavení, je tato proměnná zvýrazněna a jsou vypsány obě hodnoty.
A nyní již můžete pomocí phpMyAdmina zjistit vše co se na vašem MySQL serveru děje a jaké možnosti má zakompilovány.
Kromě správy MySQL serveru vám phpMyAdmin nabízí i možnosti jak se dozvědět zajímavé informace o jeho stavu. Sledováním těchto informací můžete optimalizovat běh vašeho MySQL serveru.
Než se pustím do rozebírání jednotlivých informací, musím upozornit, že v MySQL u vašeho provozovatele nemusíte mít oprávnění vidět všechny tyto stránky. Veškeré tyto informace jsou obvykle dostupné jen správci serveru.
Pokud chceme zjistit stav serveru, celkem logicky se podíváme na záložku nazvanou stav serveru a phpMyAdmin nás zahltí informacemi, které získal od MySQL serveru. Jak se v nich ale vyznat?
V následujících několika odstavcích si popíšeme jednotlivé položky, ale nejdříve několik obecných informací. phpMyAdmin se snaží poznat, které hodnoty jsou vyloženě špatné nebo dobré a ty barevně zvýraznit. Červené hodnoty tedy stojí za prozkoumání a ze zelených můžete mít radost, jak dobře máte MySQL server nastavený. Toto hodnocení ale vychází z průměrného používání MySQL serveru a nemusí přesně odpovídat vašemu nastavení, takže není potřeba se děsit červených čísel. Na ukázkovém serveru například najdete mnoho takových položek a to převážně z důvodu minimalizace paměťové náročnosti MySQL serveru, který tak nemůže udržovat v paměti dostatečné množství dat.
V horní části jsou souhrnné informace – celkový přenos dat a počty připojení. Tyto čísla může být zajímavé vidět, ale obvykle se zde nic zásadnějšího nedozvíme.
Hned dále je zobrazena statistika dotazů. Z té již můžeme vysledovat například převážné používání serveru. Na produkčním serveru obvykle převažují dotazy typu
select
, ale pravděpodobně zde najdete i vysoká čísla pro vkládání nových záznamů (
insert
), protože mnoho publikačních systémů si ukládá nějaké statistiky
o přístupu uživatelů. Větší četnost jiných typů dotazů může stát za prozkoumání, jestli některá aplikace není špatně nakonfigurována.
Další tabulka obsahuje některé souhrnné statistiky SQL dotazů a pokud máme vysokou hodnotu u
Slow_queries
, pravděpodobně některá aplikace příliš zatěžuje MySQL server
neoptimálními dotazy. O jaké dotazy se jednalo můžete zjistit zapnutím logování pomalých dotazů v konfiguraci MySQL (
log_slow_queries
).
V dalších částech najdete vypsaný stav jednotlivých subsystémů MySQL serveru a pokud najdete červená čísla, můžete si ve vedlejším sloupci přečíst doporučení, jak tuto hodnotu vylepšit. Kromě přehledu naleznete na konci některých tabulek i akce, které je možné se souvisejícím subsystémem provést, například vyprázdnit vyrovnávací paměť dotazů nebo zobrazit podřízené servery.
Při zkoumání vlivu jednotlivých aplikací na statistiky může být užitečné tyto statistiky občas vynulovat, k tomu vám pomůže odkaz v horní části stránky nebo případně odkazy pod jednotlivými sekcemi.
If you don't know much about things you do, work for a small company and want to look like a professional working for a big company, then the Japanese way to do this is to write following job name on your business card:
Embedded System Technical Division
Operating System Section
Chief Engineer
When I saw this for first time, I thought this business card is some kind of joke, but not, they're real.