Pull to refresh
62
0
Николай Зубач @zuborg

Highload

Send message

важно - сколько попадает на каждый пиксель.

С одной стороны - да, это важно, если кол-во пикселей одинаково.

Но с другой - при одном и том же размере сенсора наличие на нем 200М пикселей вместо 8М будет преимуществом. Да, пиксели будут меньше (для случая 200М), соответственно сильно шумнее, но все равно (даже с учётом шумности) информации для обработки будет больше. Можно просто усреднить световые интенсивности для групп пикселей - и уже сровняемся по качеству с сенсором на 8М пикселей. А можем применить алгоритм поумнее - тогда и качество будет сильно выше. Алгоритмы решают )

Да, можно.

Любой инстанс постгреса можно настроить публиковать изменения, слейв в том числе.

Интересно, как там с накладными расходами на все это счастье..

Сколько дополнительных аллокаций, сколько процессора...

При этом разница в расходе памяти была колоссальной. Всего 61 Мб при включенном HugePages, вместо 25 Гб без него.

Это было бы верно, если бы сервер показал эти освободившиеся 25Гб как free (или buff/cache, неважно), но так не бывает. Память по прежнему занята, она выделена в пул HugePages и используется процессами PostgreSQL, просто не отображается в статистике используемой процессом памяти. Поэтому может показаться, что процесс использует всего 61МБ, а по факту он работает со всеми 25Гб, как и до этого.

1) Нет никакой субъективности в том, что сумма яркостей полностью черного и белого пикселей должна равняться сумме яркостей двух пикселей c яркостью каждого в 50% (в sRGB это цвет [188,188,188]) - это можно определить и на глаз по соотв калибровочной картинке. И это только один из примеров.

2) может и подмешивает, для компенсации неточности преобразования "цифра-цвет" в мониторе, если активирован соотв профиль. Если бы преобразование "цифра-цвет" было идеальным, то во всех этих калибровках не было бы необходимости. А так приходится подавать на вход монитору "неправильную" цифру, чтобы получить "правильный" цвет.

Может быть и так (хотя мне такие цены озвучил наш отдел закупки), но тогда, получается, не оптовым покупателям все-равно нет смысла даже пробовать эту технологию, раз финансовой выгоды нет вообще, а производительность в разы меньше чем RAM.

Штука, конечно, интересная, но цена...

64GB ECC DDR4 стоит меньше 350$, а Optane 128G дешевле 700$ не найти - ну никак не получается "огромный объем за гораздо меньшие деньги, чем ДДР"

Если проблема именно в нагрузке при асинхронной записи многих файлов - можно попробовать ммапить файлы для записи, делать, собственно, запись данных в заммапленную память, а дальше пусть ОС разгребает dirty pages самостоятельно. Правда, все может упереться в задержки на page faults, я лично не тестил. Впрочем, для sparse файлов проблемы с пейжфолтами быть не должно. И придется ещё позаниматься тюнингом sysctl vm.dirty* и подобных, а то ОС может и не справиться самостоятельно, если прилетит большая пачка апдейтов.
На фре есть возможность сделать ммап с флагом MAP_NOSYNC - тогда можно отдельно синкать измененные файлы на диск (ОС это делать уже не будет), контролируя загрузку дисков..

Я бы не сказал, что прямо сильно реалистичный рендер.

Полигоны на моделях вполне бросаются в глаза, спецэффекты (дым, искры..) как в играх 10-ти летней давности, движения агентов жесткие и неестественные...

Если бы такой рендер был, скажем, в фильме, то все плевались бы.

Мне кажется, что если Вы видите пиксельную сетку (даже на FHD), то Вы сидите слишком близко к монитору.

Я сознательно поставил себе два 27" FHD монитора и работаю за ними с расстояния 100см (увеличив шрифт так что межстрочное расстояние составляет 7..11 мм) - и никаких проблем с четкостью шрифтов ))

Простота (как антоним к сложности) системы - это своего рода ресурс, им надо управлять, в частности - экономить (при проектировании), или восполнять (рефакторингом) - потраченные на это время и деньги окупаются при разумном планировании. Недостаток простоты увеличивает цену разработки и поддержки - при критически низком значении это может сыграть фатальную роль.

Спасибо за статью.

Но непонятно два момента ;)

Во первых, почему решений только 4, если их значительно больше - BACD, BADC, BCAD, BDAC, CABD, CADB, CBAD, CDAB, DABC, DACB, DBAC, DCAB?

Во вторых - почему алгоритм нашел два решения с первой вершиной "C", но только по одному для "B" и "D", хотя граф симметричный относительно B, C и D?

У друга был похожий сон: он заснул в двух потоках, после будильника один поток завершился, а второй завис.

Могу предположить, что второй поток завис потому что первый не освободил мьютекс до того как завершился по SIGALRM.

Значит, выставляем панель на 35 градусов.

Не учитывается тот факт, что зимой светлое время суток существенно меньше чем летом. Небольшим ухудшением зимнего угла падения (и соответствующим улучшением летнего) можно увеличить общую выработку энергии, за счёт большего увеличения выработки летом, чем её уменьшения зимой.

ядро 5.10, с

CONFIG_TLS=y
CONFIG_TLS_DEVICE=y

и всеми возможными шифрами

Что-то не работает KTLS на этом патченом nginx со свежерелизнутым openssl-3.0.0 (и с патченым тоже) ;(

в конфиге есть и sendfile on; и ssl_ktls on; все остальное по дефолту, ничего специфического нет.

$ssl_ktls_status в лог пишет прочерк (

user nginx nginx;
worker_processes auto;
##worker_cpu_affinity auto;
#thread_pool default threads=256 max_queue=1024;
#worker_rlimit_nofile 128000;
#timer_resolution 1ms;
#pcre_jit on;

error_log /var/log/nginx/error_log info;

events {
        worker_connections 1024;
        use epoll;
#       accept_mutex off;
}

http {
        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        log_format main
                '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '"$gzip_ratio" "$ssl_ktls_status"';

        client_header_timeout 10m;
        client_body_timeout 10m;
        send_timeout 10m;

        connection_pool_size 256;
        client_header_buffer_size 1k;
        large_client_header_buffers 4 2k;
        request_pool_size 4k;

        gzip off;

        output_buffers 2 256k;
        postpone_output 1460;

#       aio                   threads=default;
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        ssl_ktls on;

        keepalive_timeout 75 20;

        ignore_invalid_headers on;
        index index.html;

#ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
#ssl_session_cache shared:SSL:10m;
#ssl_session_timeout 30m;
#ssl_prefer_server_ciphers on;
#ssl_ciphers AES128:AES256:HIGH:!aNULL:!MD5;             # AES128 cause least CPU load


        server {
                listen *:80 default rcvbuf=32768 backlog=2048 reuseport deferred so_keepalive=5s:3:3;

                listen *:443 http2 ssl default rcvbuf=32768 backlog=2048 reuseport deferred so_keepalive=5s:3:3;
                server_name localhost;
                ssl_certificate test.crt;
                ssl_certificate_key test.crt;

                access_log /var/log/nginx/localhost.access_log main;
                error_log /var/log/nginx/localhost.error_log info;

                root /var/www/localhost/htdocs;
        }
}

Спасибо, но речь не о том, чтобы процесс получил свой стэктрейс, с этим проблем нет.

Вопрос в том, как снаружи узнать, в каком месте кода сейчас выполняется php-fpm процесс (возможна соотв модификация кода). Ну, ждет ответ от базы, например, или вычисляет что-то в какой-то функции.. С точностью до строки - вообще идеально, с точностью до функции - тоже годится. Есть ли какой-то модуль для этого?

Может кто-то знает способ получить стэктрейс для работающего в текущий момент php-fpm процесса? Чтобы понять в каком месте он выполняется в текущий момент.

Имхо, было бы правильнее сделать так, чтобы -Werror активировался не глобально, а для определённых подсистем, драйверов и т.д. Тогда можно было бы потихоньку подчищать актуальные подсистемы и драйвера от предупреждений, активировать для них -Werror и требовать чтобы последующие патчи для них компилировались чисто.

Исследования, конечно, интересные, но было бы сильно лучше, если бы подавалась и информация о результатах всех этих исследований (а не только некоторых избранных, как сейчас)

1
23 ...

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity