Re: FBReader аналог?
Oleksandr Gavenko gaven...@gmail.com wrote: On 2013-11-14, Victor Wagner wrote: On 2013.11.13 at 21:19:56 +0200, Oleksandr Gavenko wrote: Я просто переживал что книги бытие, вырыскивал по инету другие сборки, а оказывается зря время тратил - fbreader с глюками. А зачем использовать формат mobi? Еще бы lit использовали. Kindle whitepaper стоит 139$ (+ 20$ достака). И там PDF + mobi. Ближайший аналог Nook за 99$ (сейчас, раньше за 119) с PDF + ePub: http://www.barnesandnoble.com/p/nook-simple-touch-with-glowlight-barnes-noble/1108046469 Берем прошивку ZeroLab и получаем нормальный андроид + ставим кулридер и читаем всё что попадется. Но там 300 гневных коментариев - это только на оффициальной страничке, что я привел выше (по битым пикселям)! У меня уже второй нук - первому раздавил экран в кармане. Битых пикселов не замечал. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/rqf6ma-b6i@woofie.cef.spbstu.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
Bogdan bog...@gmail.com wrote: [-- text/plain, encoding base64, charset: KOI8-R, 77 lines --] 2013/11/20 Eugene Berdnikov b...@protva.ru On Wed, Nov 20, 2013 at 12:03:50PM +0300, Bogdan wrote: On Tue, Nov 19, 2013 at 11:58:33PM +0300, Bogdan wrote: Т.е. непонятно по какой причине poll() зависает на 5 секунд блокируя работу интерпретатора.^M Скорее всего, по той причине, что никаких данных по сети не приходит. Не совсем тут понятно, что значит никаких данных по сети не приходит - т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение, но данных в него не послала? Может быть и так, но возможно данные посылались и потерялись где-то по пути... Нужно не фантазировать а опираться на факт, что poll() вышел на таймаут, значит, скорее всего на хосте-приёмнике данных не было. И самый быстрый способ проверить это -- посмотреть дамп трафика. После чего уже понятно, ядро виновато или локальная сеть. Сегодня проблема воспроизвела на другом сервере, где nginx (1.2.1-2.2wheezy1) и php 5.4 на Debian 7, расположены вместе и коннект проходит сугубо через локалхост. Если через localhost - то зачем оно в tcp ходит, а не через сокет ? Выглядело это следующим образом: И кого тут подозревать? PHP или ядро, куда двигаться дальше? Для начала поставить nginx 1.4.1-3~bpo70+1 из бакпортов. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l0h6ma-spi@woofie.cef.spbstu.ru
Re: udev infinity loop when using custom rule file with RUN+= script and sfdisk
Vladimir Skubriev vladi...@skubriev.ru wrote: 22.11.2013 17:19, Artem Chuprina пишет: Vladimir Skubriev - Debian-russian@lists.debian.org @ Fri, 22 Nov 2013 15:43:47 +0400: На счет крона хорошая идея, т.к. я в принципе не планировал сразу после того, как вставил диск начинать архивирование. О ужас летящий на крыльях ночи. Повесить dnotify на /run/backup и создавать там файлик с точкой монтирования как-то проще, чем изголятся вокруг flock, cron at (который например у себя на серверах я всегда сношу. за последние 10 лет он так никогда и не пригодился). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kih6ma-spi@woofie.cef.spbstu.ru
Re: poll() timeout в PHP-FPM при получении запросов от Nginx
В первом описываемом случае был поставлен как раз тот самый Nginx из бэкпортов, на неделе поставлю оригинальную сборку последней версии предоставленную производителем. Вообще, мне кажется, дело там всё-таки в ядре либо в PHP - попытки установить соединения nginx делает, соединения в состоянии SYN_SENT и SYN_RECV в проблемные периоды существуют в количестве до двух тысяч штук каждого типа, но вот PHP что-то не получает их не смотря на валидные accept() и poll(). В пятницу уменьшил бэклог (в php-fpm, а не в sysctl) с 512 до 0 и возможно проблема перешла в новую фазу - nginx теперь периодически не может установить соединение с бэкендом, есть проблемные периоды когда соединения к php-fpm отваливаются по 20-50 штук в секунду, что плохо, но на фоне 1000-1500rps не так уж смертельно. Ну и для сравнения устанавливаю сервер на CentOS 6, поставлю там свежий PHP и Nginx, включу бэклог и посмотрю, что получится из этого. По вопросу сокета - я когда-то давно пробовал это сделать - захлёбывалось оно на каких-то совершенно незначительных величинах, причём отдебажить процесс весьма сложно - netstat информации по подключению к сокету практически не даёт, CLI-утилиты которая бы посылала FastCGI-запрос в сокет (вытащить внутренний статус из php-fpm) тоже не нашлось, короче сокеты локальные - тёмное дело. Ну и помимо прочего интересует единообразие конфигураций - у меня далеко не везде по одному сервере, обычно как минимум их два, на каждом nginx и php и запросы обрабатываются обоим перекрёстно - т.е. локальный PHP прописан первым апстримом, а php на втором-третьем-четвёртом-etc сервере - следующими, возможно с меньшим весом. 2013/11/23 Andrey Melnikoff temnota+n...@kmv.ru Bogdan bog...@gmail.com wrote: [-- text/plain, encoding base64, charset: KOI8-R, 77 lines --] 2013/11/20 Eugene Berdnikov b...@protva.ru On Wed, Nov 20, 2013 at 12:03:50PM +0300, Bogdan wrote: On Tue, Nov 19, 2013 at 11:58:33PM +0300, Bogdan wrote: Т.е. непонятно по какой причине poll() зависает на 5 секунд блокируя работу интерпретатора.^M Скорее всего, по той причине, что никаких данных по сети не приходит. Не совсем тут понятно, что значит никаких данных по сети не приходит - т.е. удалённая сторона, в данном случае nginx, установила tcp-соединение, но данных в него не послала? Может быть и так, но возможно данные посылались и потерялись где-то по пути... Нужно не фантазировать а опираться на факт, что poll() вышел на таймаут, значит, скорее всего на хосте-приёмнике данных не было. И самый быстрый способ проверить это -- посмотреть дамп трафика. После чего уже понятно, ядро виновато или локальная сеть. Сегодня проблема воспроизвела на другом сервере, где nginx (1.2.1-2.2wheezy1) и php 5.4 на Debian 7, расположены вместе и коннект проходит сугубо через локалхост. Если через localhost - то зачем оно в tcp ходит, а не через сокет ? Выглядело это следующим образом: И кого тут подозревать? PHP или ядро, куда двигаться дальше? Для начала поставить nginx 1.4.1-3~bpo70+1 из бакпортов. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l0h6ma-spi@woofie.cef.spbstu.ru -- WBR, Bogdan B. Rudas
