Новосибирская область станет пилотным регионом России для отработки сдачи ЕГЭ по информатике в электронном виде.

Новосибирская область станет пилотным регионом России для отработки сдачи ЕГЭ по информатике в электронном виде, - такая новость появилась в местных новостях. Действительно, школа, которой я помогаю с администрированием Linux, готовится к проведению такого мероприятия и я хочу чуть-чуть написать, что из себя представляет ПО, которое прислали из "центра".
 По функционирует по следующей схеме. Есть серверная часть, которая позволяет проходить все стадии экзамена: распечатку экзаменационных бланков, регистрацию и авторизацию учащихся по индивидуальным 12-значным числовым кодам, раздачу заданий, сбор результатов и проч. Клиентской частью является браузер.

Перво-наперво ПО, о котором пойдет речь, по условию должно работать в школах независимо от того, внедряли там Linux или нет. К счастью писатели КЭГЕ ("Компьютерный еге") пошли не самым плохим путем. Никаких *exe, обернутых wine в Wine. Используется java-application вместе с Tomcat. Так что весь экзаменационных инсталлер тянет на 150 Мб. Зато есть и для Win, и для x86 Linux, и для x86_64 Linux. Короче, все цивильно. В сопровождении идет объемистая документация, которая хоть и изобилует этими ужасными русскими сокращениями типа АРМ (автоматизированное рабочее место), но в остальном составлена адекватно. Примеры:


Google Chrome - Браузер, разрабатываемый компанией Google на основе свободного 
браузера Chromium.
Linux - Общее название Unix-подобных операционных систем на основе ядра Linux, библиотек и системных программ, разработанных в рамках проекта GNU.
Microsoft Internet Explorer - Серия браузеров, разрабатываемая корпорацией Microsoft. Входит в комплект операционных систем семейства Windows.

Пример из списка необходимого ПО:

FreePascal (не ниже 2.6.0) (сервер медленный, коннект не с первого раза)

Какая трогательная забота об учителях.)) Ссылки на линукс-версии исключительно на tar архивы.


Видите? Все не так плохо, как можно было бы ожидать. Напоминаю, что в школах учителя информатики могут запросто попытать подключить цифровой проектор к ноутбуку посредством инфра-красного порта. Инсталятор ПО для КЭГЕ составлен как раз для такого уровня компьютерной грамотности. Вы запускаете либо start.bat, либо start.sh и все: веб-сервер готов к работе. Он работает с тремя уровнями доступа. Только с локалхоста доступен административный интерфейс: http://localhost:8888/admin (Привет, админы локалхостов!) 
Можно или нет перенастроить ACL я сходу не понял. Зашли с локалхоста и нас тут же обломали: браузер должен быть либо > Firefox 13, либо > Chrome 19, либо >IE какой-то там. В клонах RHEL по умолчанию идет Firefox 10 как LTS. Ладно, эти грабли мы знаем, как обойти: лезем в about:config, создаем general.useragent.override и т.д. проходим первый уровень, идем дальше. 
При заходе на /admin открывается скрытый iframe и в нем проверяют коннект до ресурсов всемирной паутины, а именно до http://vk.com/images/hat.gif и в случае успеха вываливают большое красное окно: "А-та-та! Нельзя проводить экзамен на такой незащищенной системе!" Пофигу, что это [клон] RHEL 6, вдруг утечка? Ладно, локальный proxy уже есть, он в контакт не пускает, включаем в браузере. Второй уровень пройден.

Все это ПО периодически требует всевозможные ключи активации и подтверждения подлинности участников экзамена. Что само по себе похвально. Пароли и ключи для расшифровки заданий присылаются из центра. Есть также забавный термин "рассадка". Поставляется бинарный (зашифрованный?) файл с данными об учащихся, пароли доступа и проч. Прочие уровни этой занимательной игрушки уже проходил не я, но как я понял со слов человека из "центра" мы дошли дальше все, т.к. некоторые срубились уже на запуске серверной части.:) В итоге после полноценного сетапинга, ПО для экзамена знает всех поименно, рисует картинки с активированными компьютерами учеников и вобще все по-взрослому. Дизайн среднестатистический, строгий. 

https://docs.google.com/open?id=0B1Mh3B-dAA04eUdONDNWVmQ2bUk

iostat -x

This is reposting on an article from http://dom.as/2009/03/11/iostat/ which I liked very much.

My favorite Linux tool in DB work is ‘iostat -x’ (and I really really want to see whenever I’m doing any kind of performance analysis), yet I had to learn its limitations and properties. For example, I took 1s snapshot from a slightly overloaded 16-disk database box:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    2.57   21.65    0.00   67.66

Device:  rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s \
sda     7684.00    19.00 2420.00  498.00 81848.00  5287.00 \

        avgrq-sz avgqu-sz   await  svctm  %util
           29.86    32.99   11.17   0.34 100.00

I pasted this somewhere on IRC, and got “doesn’t look too healthy” and that it is disk-bound. Now, to understand if it really is, one has to understand what iostat tells here.
First line of numbers shows that we’ve got plenty of CPU resources (thats because nowadays it is quite difficult to get a box with not enough CPU power, and I/O still seems to be bottleneck) – and we have more threads waiting for I/O than we have CPU execution (that sounds normal).
Now the actual per-disk statistics are where one should look. I used to prefer %util over general %iowait (I couldn’t really explain what %iostat is, and I can say what %util is). I don’t know why, but iostat has most interesting bits at the end, and not so interesting at the start:

• %util: how much time did the storage device have outstanding work (was busy). In proper RAID environments it is more like “how much time did at least one disk in RAID array have something to do”. I’m deliberately excluding any kind of cache here – if request can be served from cache, the chance is quite negligible it will show up in %util, unlike in other values. What this also means – the RAID subsystem can be loaded from 6.25% (one disk doing the work) to 100% (all of them busy). Thats quite a lot of insight in single value of ’100%’, isn’t it?
• svctm: Though manual says “The average service time (in milliseconds) for I/O requests that were issued to the device.”, it isn’t exactly that when you look at multiple-disk systems. What it says is, “when your I/O subsystem is busy, how fast does it respond requests overall”. Actually, less you load your system, higher svctm is (as there’re less outstanding requests, and average time to serve them goes up). Of course, at some certain moment, when I/O becomes really overloaded, you can see svctm going up. One can tweak /sys/block/sda/queue/nr_requests based on this – to avoid overloading I/O controller, though that is really rarely needed.
• await. One of my favorites – how fast do requests go through. It is just an average, how long it takes to serve a request for a device, once it gets into device queue, to final “OK”. Low = good, high = bad. There’re few gotchas here – even though different reads can have different performance properties (middle of disk, outer areas of disk, etc), the biggest difference is between reads and writes. Reads take time, writes can be instant (write caching at underlying layers..). As 80% of requests were reads, we can try to account for that by doing 11.17/0.8 math, to get 14ms figure. Thats quite high – systems that aren’t loaded can show ~5ms times (which isn’t that far away from 4ms rotation time of 15krpm disk).
• avgqu-sz: Very very very important value – how many requests are there in a request queue. Low = either your system is not loaded, or has serialized I/O and cannot utilize underlying storage properly. High = your software stack is scalable enough to load properly underlying I/O. Queue size equal to amount of disks means (in best case of request distribution) that all your disks are busy. Queue size higher than amount of disks means that you are already trading I/O response time for better throughput (disks can optimize order of operations if they know them beforehand, thats what NCQ – Native Command Queueing does). If one complains about I/O performance issues when avgqu-sz is lower, then it is application specific stuff, that can be resolved with more aggressive read-ahead, less fsyncs, etc. One interesting part – avqu-sz, await, svctm and %util are iterdependent ( await = avgqu-sz * svctm / (%util/100)
• avgrq-sz: Just an average request size. Quite often will look like a block size of some kind – can indicate what kind of workload happens. This is already post-merging, so lots of adjacent block operations will bump this up. Also, if database page is 16k, though filesystem or volume manager block is 32k, this will be seen in avgrq-sz. Large requests indicate there’s some big batch/stream task going on.
• wsec/s & rsec/s: Sectors read and written per second. Divide by 2048, and you’ll get megabytes per second. I wanted to write this isn’t important, but remembered all the non-database people who store videos on filesystems :) So, if megabytes per second matter, these values are important (and can be seen in ‘vmstat’ output too). If not, for various database people there are other ones:
• r/s & w/s: Read and write requests per second. This is already post-merging, and in proper I/O setups reads will mean blocking random read (serial reads are quite often merged), and writes will mean non-blocking random write (as underlying cache can allow to serve the OS instantly). These numbers are the ones that are the I/O capacity figures, though of course, depending on how much pressure underlying I/O subsystem gets (queue size!), they can vary. And as mentioned above, on rotational media it is possible to trade response time (which is not that important in parallel workloads) for better throughput.
• rrqm/s & wrqm/s: How many requests were merged by block layer. In ideal world, there should be no merges at I/O level, because applications would have done it ages ago. Ideals differ though, for others it is good to have kernel doing this job, so they don’t have to do it inside application. Quite often there will be way less merges, because applications which tend to write adjacent blocks, also tend to wait after every write (see my rant on I/O schedulers). Reads however can be merged way easier – especially if application does “read ahead” block by block. Another reason for merges is simple block size mismatch – 16k database pages on top of 8k database pages will cause adjacent block reads, which would be merged by block layer. On some systems read of two adjacent pages would result in 1MB reads, but thats another rant :)
• Device: – just to make sure, that you’re looking at the right device. :-)

So, after all this, the iostat output above tells us something like:

• System has healthy high load (request queue has two-requests-per-disk)
• Average request time is double the value one would expect from idle system, it isn’t too harmful, but one can do better
• It is reading 80 40MB/s from disks, at 2420 requests/s. Thats quite high performance from inexpensive 2u database server (shameless plug: X4240 :)
• High amount of merges comes from LVM snapshots, can be ignored
• System is alive, healthy and kicking, no matter what anyone says :)

Why Linux is ahead of Windows

It is known, that Windows 8 will get support for a new security feature called Intel SMEP. I'll omit the description what's that for because more important is Linux has had this feature since spring of the last year! And that is not all of it! Today one more technology that is to debut in next year's Intel Haswell line of processors got it's way into Linux kernel. Supervisor Mode Access Prevention.
http://www.phoronix.com/scan.php?page=news_item&px=MTE5NzI
http://forums.grsecurity.net/viewtopic.php?f=7&t=3046
Man, don't ask me, when Windows is going to get that!