LINUX.ORG.RU

2
Всего сообщений: 31

boost interprocess валится при удалении общей памяти из библиотеки

Доброго всем времени суток. Использую boost::interprocess::shared_memory_object для выделения общей памяти при межпроцессном взаимодействии, но shared_memory_object живёт в библиотеке и при вызове boost::interprocess::shared_memory_object::remove программа падает, если этот же код выполнить просто в исполняемом файле, то всё пройдёт отлично. Подскажите что я делаю не так?

Нижеприведённый код будет работать в исполняемом файле, но упадёт при remove (последняя строка), если его вынести в библиотеку

    namespace bip = boost::interprocess;
    std::unique_ptr pMem = std::make_unique<bip::shared_memory_object>(bip::create_only, "Name", bip::read_write);
    pMem->truncate(4);
    std::unique_ptr pMemReg = std::make_unique<bip::mapped_region>(*pMem.get(), bip::read_write);

    char *ar=nullptr;
    ar = static_cast<char*>(pMemReg->get_address());
    std::memset(ar,0,4);
    ar[0]=1;
    ar[1]=2;

    bip::shared_memory_object::remove("Name");

Похоже проблема проявляется только под виндой, под линуксом всё работает

 , ,

seijuurou ()

Xorg и разделяемая память

«Команды протокола X11 могут передаваться как через разделяемую память или локальное соединение (если X-клиент и X-сервер запущены на одном компьютере), так и по сети – при этом X-клиент и X-сервер могут быть запущены на разных компьютерах.»

http://gentoo.theserverside.ru/book/ar68s19.html

Это интересно, где можно про это прочитать подробнее? Я то считал, что команды всегда передаются через sockets API. А тут оказывается, что не всегда.

 ,

Einstok_Fair ()

Разделяемая память для процессов на Python и не только.

Привет всем!

Есть большое многопроцессное приложение, с рабочими процессами, всякими GUI и логгерами в отдельных процессах и т.д. Построено с использованием модуля multiprocessing. Рабочие процессы обрабатывают большие данные. Для больших данных используется multiprocessing.Array, вот так:

class Worker(mp.Process):
    def __init__(self, buffers, pipe, other):
        super().__init__()
        self._buffers = buffers
        self._pipe = pipe
    def run(self):
        param = get_message(self._pipe)
        big_calculations(self._buffers[param.a], param.b, ...)

buffers = []
for i in range(10):
    buffers.append(mp.Array(ctypes.c_uint8, buffer_size, lock=False))
...
for i in range(10):
    p1, p2 = mp.Pipe()
    worker = Worker(buffers, p1, other_param)
    worker.start()
Синхронизация от mp.Array не требуется, процессы синхронизируются с помощью посылки/отправки сообщений через p1/p2, поэтому lock=False.

Вопросы:
* Размер/количество буфера(ов) задаются до запуска рабочих процессов. Как правильно реализовать изменение количества/размера после того, как рабочие процессы уже стартовали? Т.е. понятно, как отправить сообщение. Непонятно как закрыть существующий буфер и открыть новый.
* Что у mp.Array под капотом? Я заметил, что python открывает много файлов с именами вида /tmp/pymp-ixc54qx7/pym-27111-h7wi_sy3. Это как-то связано с mp.Array?
* Очень желательно, чтобы к этой общей памяти можно было обращаться не только из процессов на Python. Возможно как-либо её открыть из другого стороннего процесса, написанного на чём-то ещё? Может быть мне тогда что-то другое использовать, а не mp.Array?

Аналогичные вопросы про mp.Pipe():
* Как в работающий процесс передать конец новой трубы?
* Как передать в не Python'овский процесс конец трубы?

Спасибо!

 , , , ,

ls-h ()

Разделяемая память и ее защита.

Добрый вечер, форумчане!

Имеется вопрос, есть в проекте (операционка QNX4.25) несколько разделяемых объектов памяти, для взаимодействия между процессами. Есть один писатель в каждую из них и несколько читателей, я написал несколько функций оберток вида:

void XXXX_ShmemLock()
{
	assert( g_Shmem );
	sem_wait( &g_Shmem->lock );
}

void XXXX_ShmemUnlock()
{
	assert( g_Shmem );
	sem_post( &g_Shmem->lock );
}

void XXXX_ShmemCopy( void *destination, const void *source, const size_t num )
{
	XXXX_ShmemLock();
	_disable();
	memcpy( destination, source, num );
	_enable();
	XXXX_ShmemUnlock();
}

Дальнейшие операции более высокого уровня, выполняются путем вызова функций-оберток, как пример приложу:

void XXXX_ReadADC( const ADCChannel_t channel, double *voltage )
{
	assert( channel < ADC_ChannelsNum );
//	*voltage = g_Shmem->Vin[channel];
	XXXX_ShmemCopy( (void *)voltage, (const void *)&g_Shmem->Vin[channel], sizeof(g_Shmem->Vin[channel]) );
}

void XXXX_WriteADC( const ADCChannel_t channel, const double voltage )
{
	assert( channel < ADC_ChannelsNum );
//	g_Shmem->Vin[channel] = voltage;
	XXXX_ShmemCopy( (void *)&g_Shmem->Vin[channel], (const void *)&voltage, sizeof(voltage) );
}
P.S. Насколько рационален такой подход?

Так вот, как видно в функции XXXX_ShmemCopy, копирование данных в область и из нее, производится вызовом memcpy, обернутым в семафор и дополнительным отключением прерываний на момент копирования, чтобы обеспечить атомарность операции. Есть ли вообще смысл в такой перестраховке на однопроцессорной системе? Минус в использовании _disable()/_enable() при больших объемах копирования (которых скорее всего не будет), на момент выполнения операции, стопорится работа всей системы, или если вызовов XXXX_ShmemCopy будет много (а их скорее всего будет много), то рискуем то и делать что бесконечно выключать/включать прерывания. Так же есть ли необходимость оборачивания простых операций вида «Область->переменная = что-то записать», понятное дело не делая справа от «=» сложных операций, будет ли такая операция выполнена атомарно?

 , , , ,

subuser ()

Хочу межпроцессное взаимодействие через /dev/shm

Есть две JVM, которым нужно общаться друг с другом. Как открыть, а затем читать/писать в /dev/shm/foo понятно. Непонятно как уведомить читателя, что началась запись, и он может выйти из спячки и начать чтение?

Вот смотрю какие-то futex-ы есть, кто-то советует файл блокировать, какие еще есть методы? Что легковеснее?

 , ,

foror ()

Какой вариант расшаривания большого и толстого хеша вы бы предпочли и почему?

Что-то вроде опроса среди перловодов :)

Хинт: Структура данных периодически (от раза в 15 секунд до раза в 10 минут) изменяется. Размер структуры данных незначительно, но тоже изменяется. Процессы все в рамках одной машины. Но нет, это не процессы в рамках Apache/mod_perl. «Потребители» читают структуру данных целиком, а потом просто получают её апдейты, поэтому хранить её как-то по частям нет никакого смысла.

Варианты ответов:

1) Засунул бы в ключ NoSQL'я (Redis/Tarantool/MongoDB), засериализовав её в JSON/CBOR/BSON/MessagePack и т.д. - нехай кому надо get'ом забирают.

2) Засунул бы в IPC Shared Memory, пусть из оперативы без посредников качают и десериализуют всё как надо

3) Поднял бы сокет UNIX/TCP - и отдавал бы сериализованное всем желающим по запросу

4) Использовал бы какие-нибудь варианты наподобие очередей и b(lpop) в Redis для организации своеобразного RPC на базе NoSQL-ки

5) Использовал бы File::Map или подобные mmap-штуки, сделав файл изначально процентов на 20 больше сериализованной структуры, чтобы учитывать даже самые зверские флуктуации её размера (как тогда «подрезать» считанное из map'а до реального размера, чтобы десериализовать?)

Лично мне милы варианты 1 и 5. А вам?

«Спасибо за внимание, дети мои, с вами был я, Три-дог-найт, на волне вашего любимого Радио, Новости Галактики!» (С)

 ,

DRVTiny ()

shared memory + cond variables + mutexes

доброго дня!

пытаюсь протестирвоать следующую обвязку. Процесс Producer + процесс Consumer (независимые процесс). Обмен данными идет по shared memory с использованием мьютекса и условной переменной, которые запилены в структуре, которая помещаяется в shared memory.

Вопрос - почему когда умирает producer, mutex остается навечно залоченным и соответственно consumer не может его захватить?

Предполагаю, что это такая фича мьютексов, так как при умирании продюсера этот мутекс так и остается залоченным.

Как можно сделать так, чтобы при падении продюсера скидывать лок с его мьютекса?

Заранее спасибо,

 , ,

elmir_k ()

Просмотр графа загруженных процессами в раму библиотек

Насколько я понимаю, при обновлении работающей системы нередка ситуация, когда свежезапущенные процессы используют обновлённую версию библиотеки, а долгоиграющие продолжают держать в раме старую. В итоге одно из главных преимуществ GNU/Linux — шаринг библиотек между процессами — теряет силу. Да и с точки зрения безопасности это нехорошо. Есть готовые инструменты, которые выводят граф подгруженных процессами библиотек и помогают принять решение, не пора ли бы перезапустить некоторые устаревшие процессы, а то и вовсе перезагрузить систему, если обновилось что-то базовое?

 , , , ,

bodqhrohro_promo ()

Этот ваш кривой Shared Memory. Часть вторая

Итак, после включения костылика количество мёртвых записей кардинально поубавилось и за пределы полутора сотен не вылезает. Но проблемы на этом не закончились.

По работе надо частенько из журнала запросов или консоли браузерных девтулзов копировать JSON'ы. Всё хорошо, пока оные не достигают внушительных размеров, проблемы начинатся уже где-то с 250 килобайт, а JSON'ы бывают и куда большими. Копирование зачастую происходит не до конца. Из-за этого я начал пропускать JSON'ы через преттифаер: pbpaste|jq . > /tmp/%filename%. Если обкоцанный — он ругнётся. Размер обкоцанного буфера постоянно разный, часто проскакивают 2¹⁸ и её суммы, но бывают и какие-то совсем странные числа.

Сначала я пенял на место на системном разделе. Менеджерами буфера обмена из соображений секурности не пользуюсь, то есть копирование происходит напрямую из процесса в процесс. Однако с какого-то предела жирности в /tmp кладутся файлы clipboardcache-*. В любом случае, эти файлы тоже оказываются недописанными, при том, что места полгига там есть.

Сегодня при подобных попытках успешно записать содержимое буфера обмена в файл браузер-источник вообще начал эпизодически падать. Тут-то я и обратил более пристальное внимание на сабж. Количество записей, как и обычно, не смутило. Решил посчитать размер.

root@localhost:/home/bodqhrohro/Загрузки# ipcs -a|grep dest|col5|paste -sd+|bc
606731544
ЩИТО? Ну ладно всякие там храмеум-базед активно гоняют данные между вкладками, но и для них это перебор. Глянул ipcs -p, вычисляю первого попавшегося жиробаса на 64 МБ. PID создателя принадлежит dunst. PID последнего доступателя — некий 27778, которого и след давно простыл. Перезапустил dunst, смотрю — там ещё куча записей от мёртвого 27778. С emerald, например, расшарено 8 МБ — иконка, что ли? Главное, этих почищенных 64 МБ уже хватило, чтобы чтение буфера обмена успешно отработало с первый попытки.

И что, спрашивается, с такими мёртвыми жиробасами делать? Если определённо мёртвые записи я чистил смело, то тут очкую — один из использующих процессов-то ещё жив.

 , , , ,

bodqhrohro_promo ()

Нехватка SHM

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

Смотрел strace клиента, но безрезультативно; перед смертью процесс пытался читать файлы сокетов в /tmp и падал. Только сегодня поскроллил чуть выше и заметил, что на одном из таких обращений кидает ENOSPC. Немного посёрчив, как такое может быть, и неоднократно убедившись, что лимит SHM у меня запредельный, начал копать, как её может не хватать фактически.

И докопался. В ipcs -a было четыре тысячи записей. Соорудил скрипт для очистки сирот (с nattch=0):

ipcs -a|awk '{printf $2" "$6"\n"}'|grep ' 0$'|col1|while read a; do ipcrm -m "$a"; done
Только начало чистить — сервер радостно запустил клиент. После полного выполнения записей стало всего сотня.

Вопросы:

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

2) какого хрена оно само не чистится, почему я должен пердолить скрипты? Хорошо, что я умею, а какой-нибудь убунтёнок поднял бы визг, и ему ничем бы не смогли помочь, потому что проблема локальная и трудновоспроизводимая

3) насколько ССЗБизм вот так чистить? Вдруг лишнего вычищу и кого-то запущенного поломаю.

 , , ,

bodqhrohro_promo ()

fork() и возможность шарить уже выделенные страницы памяти

Возможно ли после fork'а расшарить между процессами выделенные процессу ДО fork'а участки памяти?

С моей тчоки зрения, это было бы разумным дополнением к Copy On Write стратегии: помимо концепции «копирования при необходимости» должна быть стратегия «совместно используемых участков памяти».

Это бы в корне отличалось от IPC Shared Memory, поскольку последняя system-wide и должна выделяться специально обученными методами, а тут - мы просто имеем дело с куском памяти, совместно используемым мастер-процессом и его потомками.

Где-то как это реализовано, я говорю о том, что всегда было и самоочевидно или же «я опять хочу невозможного»?

 ,

DRVTiny ()

Совместное использование ресурсов

Есть проблема доступа к совместным ресурсам. Я вот не пойму, это реальная проблема, или она надумана?

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

Пусть есть условная ячейка памяти, которую разные процессы могут инкрементить. Как принято представлять эту модель? Процесс №1 считывает текущее значение из памяти(допустим - это 0), прибавляет к нему единицу, а затем записывает в память получившееся значение вместо предыдущего. Соответственно пока процесс №1 производит операцию сложения, процесс №2 может считать значение памяти, и начать свою операцию сложения. Затем, после того как процесс №1 записал результат(1) в память, процесс № 2 также записывает свой результат(1) в память, и результат 2-х инкрементов — 1.

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

Это все выглядит уродливо, как кровавое месиво.

Давайте посмотрим на это с другой стороны.

Есть условная ячейка, к которой имеет доступ только один процесс, который умеет ее инкрементить. Остальные процессы могут послать сообщения этому процессу, с «просьбой» инкрементации. При этом, эти мессенджеры абстрагированны от текущего значения счетчика, нет нужды считывать значения и производить собственные операции над этим значением, их дело — послать собщение и все. Они не имеют никакого доступа к этой памяти.

То есть, обычная инкапсуляция. И нет никакой проблемы.

Если это так просто, то зачем городить огород? Зачем решать несуществующие проблемы? Может это выгодно всякого рода горе-дезигнерам, делать вид, что существует проблема, нет проблемы — нет и хлебушка с маслицем?

Перемещено tailgunner из development

Перемещено jollheef из job

 , ,

vikingfilmtracker ()

Динамические структуры данных в shared memory.

Всем привет. Интересует вопрос возможности создания динамический структур данных в разделяемой памяти, либо альтернативы этому.

Есть демон. Один main-процесс и несколько форкнутых воркеров. В качестве IPC используется разделяемая память. Через shmat выделяется кусок памяти, где хранятся общие используемые структуры. Все устраивает, кроме одного, нельзя использовать STL-контейнеры. Приходится делать все на обычных массивах и наступать на ограничения, которые связаны с этим.

Некоторые «workaround», которые пришли в голову:

  • Использовать boost::ipc. Писать свои кастомные алокаторы.
  • Не форкаться. Создавать треды, тогда контейнеры использовать можно, нужно лишь позаботиться об мьютексах и т.д. и т.п.
  • Не использовать разделяемую память. Поставить тот же Redis и хранить все в нем.

Есть ли еще какие-то варианты в моем случае?

Заранее спасибо за ответы.

 , , ,

netcreeper ()

Странные проблемы shared memory и не запускающийся zabbix_agent

Здравствуйте, господа.

Скомпилил я ядро и с помощью debootstrap поставил debian 8.2 на свой Cubieboard.

поставил zabbix-agent из реп. Но вот беда, он не стартует. Проверил лог и нашел там

zabbix_agentd [14787]: cannot create Semaphore: [38] Function not implemented
zabbix_agentd [14787]: unable to create mutex for log file

При гуглении наткнулся на решение вот тут https://www.zabbix.com/forum/showthread.php?t=16561

Оказалось что нужно увеличить shared memory. Но тут началось самое интересное.. в /proc/sys/kernel/ у меня нет ни shmall ни shmmax и вот такое решение:

/sbin/sysctl -w kernel.shmall=40960000
/sbin/sysctl -w kernel.shmmax=204800000
попросту не работает, выдавая:
sysctl: cannot stat /proc/sys/kernel/shmall: No such file or directory
Подозреваю, что я что-то забыл добавить во время сборки ядра, но не знаю что. Подскажите, пожалуйста, что же потерялось?

От безысходности я даже собрал zabbix_agent из сорцов- такая же проблема

 ,

disee ()

Разделяемая память Red Hat

При установке Заббикс-сервера столкнулся с проблемой: недостаточно разделяемой памяти. После поиска в гугле стало ясно, что нужно изменить значения переменных kernel.shmall и kernel.shmmax (по умолчанию стоят 2097152 и 33554432). Подскажите пожалуйста, какими нужно брать данные значения, так как везде пишут по разному(где то нужно выделить под kernel.shmmax всю память целиком, где то половину, так же есть скрипты с непонятными формулами). Сама система: Red hat linux 6 x86_64, 6 Гб ОЗУ.

 ,

igor757 ()

Системный вызов read для shm, pipe

1. Для считывания данных из stdin используется syscall read, но как дела обстоят с shared memory?
2. Будет ли сказываться на работе системы нагруженный IO при работе с пайпами? Копирование данных на флешку, например, приводит к сильным зависаниям системы (нагрузка процессора при этом не больше нескольких процентов).
3. Есть ли операционные системы, где системный вызов read находится в пространстве пользователя? Увеличится ли при этом скорость отправки данных? Нужно ли?
4. В каком виде будет храниться массив в shm?

 , , , ,

sharkvi ()

Использование памяти: slab cache kmalloc-1024

Пожалуйста помогите понять, что тут с памятью на этом сервере. Я запутался в разных структурах: Filesystem cache, slab (почему такой большой?) и др. Вычитал, что при необходимости, линукс автоматически освобождает области памяти, которую использует для кэша файловой системы.

Но одна утилита показывает одно, другая другое и я запутался просто уже.

Всего 198 гб RAM. 2 Gb swap RHEL7 Veritas SFHA / Oracle 11

Вот что показывают разные утилиты:

[root# ] free -m
             total       used       free     shared    buffers     cached
Mem:        193274     192171       1102      59758          2       8504
-/+ buffers/cache:     183664       9609
Swap:         2047          0       2047
[root# ] top
top - 10:42:01 up 34 days, 14:40,  6 users,  load average: 0.19, 0.34, 0.48
Tasks: 1117 total,   1 running, 1116 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.8 us,  0.6 sy,  0.0 ni, 98.5 id,  0.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  19791316+total, 19680355+used,  1109612 free,     2896 buffers
KiB Swap:  2097148 total,        0 used,  2097148 free.  8708480 cached Mem
  Mem[||||||||||||||||||||||||||||||||||||||||||||#********123908/193274MB]     Tasks: 468, 280 thr; 1 running
  Swp[                                                            0/2047MB]     Load average: 0.14 0.31 0.47 

[root# ] vmstat -S m 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0   1303      2   8921    0    0  1036   102    1    1  1  1 98  0  0
 1  0      0   1304      2   8921    0    0   380  2014 8096 13953  1  0 99  0  0
 0  0      0   1313      2   8921    0    0   124    48 8539 13464  1  0 99  0  0
 0  0      0   1313      2   8921    0    0    64    64 7218 13603  0  0 100  0  0
 2  0      0   1291      2   8921    0    0    72  1084 8212 14997  1  1 98  0  0
 0  0      0   1312      2   8921    0    0  1208    83 7777 14391  1  0 99  0  0
 0  0      0   1297      2   8921    0    0  2144   143 7894 15025  1  1 99  0  0
 0  0      0   1282      2   8921    0    0   128   267 7482 13971  0  0 99  0  0
 0  0      0   1267      2   8921    0    0     0    43 7163 13487  1  0 99  0  0
 0  0      0   1266      2   8921    0    0     0    64 6845 13379  0  0 100  0  0

Особенно тут пугает kmalloc-1024:

[root# ] vmstat -m
Cache                       Num  Total   Size  Pages
cifs_request                 47     51  16512      1
cifs_inode_cache           1015   1395    728     45
nfs_direct_cache              0      0    208     39
nfs_commit_data             736    736    704     46
nfs_read_data               576    576    896     36
nfs_inode_cache             867   1426   1056     31
fscache_cookie_jar          102    102     80     51
llt64k_05/13/2015_18:01:38      0      0  65536      1
llt32k_05/13/2015_18:01:38      0      0  32768      1
llt16k_05/13/2015_18:01:38      0      0  16384      2
nf_conntrack_ffff882fba240000      0      0    312     26
nf_conntrack_ffffffff819a09c0   2568   2990    312     26
vx_pgbh                  1177901 1182690     24    170
vx_pglnk                  17952  17952     40    102
vx_iowr                     476    476    584     28
vx_wb_logrec_t                0      0    128     32
vx_sum_sum                  826   1036    288     28
vx_icfs                       0      0    272     30
ext4_inode_cache           2646   2809    984     33
ext4_xattr                    0      0     88     46
ext4_allocation_context   17220  17220    136     30
ext4_io_end                5312   5312     64     64
jbd2_journal_handle       21318  21624     40    102
jbd2_journal_head          5760   5760    112     36
jbd2_revoke_table_s         256    256     16    256
jbd2_revoke_record_s      23296  23936     32    128
kvm_vcpu                      0      0  16064      2
kvm_mmu_page_header           0      0    168     24
nfsd4_delegations             0      0    368     44
nfsd4_openowners              0      0    392     41
rpc_inode_cache              75     75    640     25
xfs_dqtrx                     0      0    576     28
xfs_icr                       0      0    144     28
xfs_ili                    8768  16016    152     26
xfs_inode                471572 487040   1024     32
xfs_efd_item               2120   2290    400     40
xfs_da_state                528    528    488     33
xfs_btree_cur             12870  12870    208     39
xfs_log_ticket             1408   1408    184     44
scsi_cmd_cache             1444   1836    448     36
kcopyd_job                    0      0   3312      9
dm_uevent                     0      0   2608     12
dm_rq_target_io               0      0    424     38
UDPLITEv6                     0      0   1152     28
UDPv6                       448    448   1152     28
tw_sock_TCPv6              1376   1728    256     32
TCPv6                       256    256   2048     16
cfq_queue                  3321   3356    232     35
bsg_cmd                       0      0    312     26
mqueue_inode_cache          108    108    896     36
Cache                       Num  Total   Size  Pages
hugetlbfs_inode_cache        78     78    608     26
configfs_dir_cache            0      0     88     46
dquot                      1952   2272    256     32
pid_namespace                30     30   2176     15
posix_timers_cache           99     99    248     33
UDP-Lite                      0      0   1024     32
ip_fib_trie                  18    292     56     73
RAW                        1454   1598    960     34
UDP                         512    512   1024     32
tw_sock_TCP                 608    928    256     32
TCP                         969    969   1920     17
blkdev_queue                510    510   1920     17
blkdev_requests           95327  95676    384     42
blkdev_ioc                 2228   2418    104     39
fsnotify_event_holder     66810  66810     24    170
fsnotify_event             6764   7106    120     34
sock_inode_cache           1625   1625    640     25
net_namespace                14     14   4224      7
shmem_inode_cache          9406   9432    680     24
Acpi-ParseExt              2355   2464     72     56
Acpi-Namespace            11526  11526     40    102
taskstats                  6360   6360    328     24
proc_inode_cache          63990  65232    656     24
sigqueue                    450    450    160     25
bdev_cache                  897    897    832     39
sysfs_dir_cache          101577 101772    112     36
inode_cache               22077  22086    592     27
dentry                   447270 447846    192     42
iint_cache                    0      0     80     51
selinux_inode_security   167218 176001     80     51
buffer_head               83926  84045    104     39
vm_area_struct            60397  60680    216     37
mm_struct                  1416   1480   1600     20
files_cache                3075   3075    640     25
signal_cache               2282   2548   1152     28
sighand_cache              1523   1680   2112     15
task_struct                1734   2288   2912     11
anon_vma                  29845  31040     64     64
shared_policy_node         4177   4505     48     85
numa_policy                2356   2356    264     31
radix_tree_node          376729 534387    584     28
idr_layer_cache             585    585   2112     15
dma-kmalloc-8192              0      0   8192      4
dma-kmalloc-4096              0      0   4096      8
dma-kmalloc-2048              0      0   2048     16
dma-kmalloc-1024              0      0   1024     32
dma-kmalloc-512              32     32    512     32
dma-kmalloc-256               0      0    256     32
dma-kmalloc-128               0      0    128     32
dma-kmalloc-64                0      0     64     64
Cache                       Num  Total   Size  Pages
dma-kmalloc-32                0      0     32    128
dma-kmalloc-16                0      0     16    256
dma-kmalloc-8                 0      0      8    512
dma-kmalloc-192               0      0    192     42
dma-kmalloc-96                0      0     96     42
kmalloc-8192                235    264   8192      4
kmalloc-4096                743    792   4096      8
kmalloc-2048               1245   1328   2048     16
kmalloc-1024             115117700 115117756   1024     32
kmalloc-512              1396580 1535360    512     32
kmalloc-256              729999 740544    256     32
kmalloc-192              110173 111846    192     42
kmalloc-128              536467 573216    128     32
kmalloc-96               102388 104244     96     42
kmalloc-64               491454 580352     64     64
kmalloc-32                29082  30208     32    128
kmalloc-16                68032  70400     16    256
kmalloc-8                 34304  34304      8    512
kmem_cache_node             760    768     64     64
kmem_cache                  352    352    256     32

И вот статистика за последний день (atopsar):

[root# ] atopsar -m

dbhost 3.10.0-123.el7.x86_64  #1 SMP Mon May 5 11:16:57 EDT 2014  x86_64  2015/06/17

-------------------------- analysis date: 2015/06/17 --------------------------

00:00:01  memtotal memfree buffers cached dirty slabmem  swptotal swpfree _mem_
00:10:01   193274M    527M      2M 73150M    0M 113293M     2047M   2047M
00:20:01   193274M    594M      2M 72998M    0M 113301M     2047M   2047M
00:30:01   193274M    657M      2M 72897M    0M 113304M     2047M   2047M
00:40:01   193274M    727M      2M 72954M    0M 113310M     2047M   2047M
00:50:01   193274M    579M      2M 73091M    0M 113316M     2047M   2047M
01:00:01   193274M    520M      2M 73138M    0M 113319M     2047M   2047M
01:10:01   193274M    523M      2M 73134M    0M 113325M     2047M   2047M
01:20:01   193274M    504M      2M 73148M    0M 113328M     2047M   2047M
01:30:01   193274M    652M      2M 73110M    0M 113331M     2047M   2047M
01:40:01   193274M    651M      2M 73114M    0M 113332M     2047M   2047M
01:50:01   193274M    655M      2M 73116M    0M 113331M     2047M   2047M
02:00:01   193274M    578M      2M 73083M    0M 113341M     2047M   2047M
02:10:01   193274M   1740M      2M 72032M    0M 113336M     2047M   2047M
02:20:01   193274M   1721M      2M 72035M    0M 113336M     2047M   2047M
02:30:01   193274M   1747M      2M 72037M    0M 113335M     2047M   2047M
02:40:01   193274M   1310M      2M 72465M    0M 113340M     2047M   2047M
02:50:01   193274M   1319M      2M 72466M    0M 113340M     2047M   2047M
03:00:01   193274M   1248M      2M 72469M    0M 113340M     2047M   2047M
03:10:01   193274M   1038M      2M 72634M    0M 113341M     2047M   2047M
03:20:01   193274M   1027M      2M 72635M    0M 113341M     2047M   2047M
03:30:01   193274M   1044M      2M 72649M    0M 113340M     2047M   2047M
03:40:01   193274M    813M      2M 72804M    0M 113364M     2047M   2047M
03:50:01   193274M    989M      2M 72753M    0M 113363M     2047M   2047M
04:00:01   193274M    991M      2M 72754M    0M 113363M     2047M   2047M
04:10:01   193274M    823M      2M 72902M    0M 113367M     2047M   2047M
04:20:01   193274M   1765M      2M 71516M    0M 113814M     2047M   2047M
04:30:01   193274M   2246M      2M 70716M    0M 113982M     2047M   2047M
04:40:01   193274M  12611M      2M 60161M    0M 114039M     2047M   2047M
04:50:01   193274M  12915M      2M 60163M    0M 114038M     2047M   2047M
05:00:01   193274M  12914M      2M 60164M    0M 114038M     2047M   2047M
05:10:01   193274M  12240M      2M 60558M    0M 114048M     2047M   2047M
05:20:01   193274M  12101M      2M 60950M    0M 114055M     2047M   2047M
05:30:01   193274M  12086M      2M 60951M    0M 114056M     2047M   2047M
05:40:01   193274M  10425M      2M 62158M    0M 114082M     2047M   2047M
05:50:01   193274M  10840M      2M 62182M    0M 114083M     2047M   2047M
06:00:01   193274M  10820M      2M 62183M    0M 114083M     2047M   2047M
06:10:01   193274M   9844M      2M 62988M    0M 114099M     2047M   2047M
06:20:01   193274M   6635M      3M 65705M    0M 114110M     2047M   2047M
06:30:01   193274M   7151M      3M 65719M    0M 114112M     2047M   2047M
06:40:01   193274M   7166M      3M 65719M    0M 114113M     2047M   2047M
06:50:01   193274M   7164M      3M 65720M    0M 114112M     2047M   2047M
07:00:01   193274M   6781M      3M 65725M    0M 114112M     2047M   2047M
07:10:01   193274M   7003M      3M 65732M    0M 114113M     2047M   2047M
07:20:01   193274M   6976M      3M 65741M    0M 114113M     2047M   2047M
07:30:01   193274M   6585M      3M 66133M    0M 114116M     2047M   2047M
07:40:01   193274M   6035M      3M 66526M    0M 114125M     2047M   2047M
07:50:01   193274M   6030M      3M 66529M    0M 114128M     2047M   2047M
08:00:01   193274M   6044M      3M 66531M    0M 114128M     2047M   2047M
08:10:01   193274M   5526M      3M 66538M    0M 114128M     2047M   2047M
08:20:01   193274M   5558M      3M 66543M    0M 114130M     2047M   2047M
08:30:01   193274M   5057M      3M 66933M    0M 114134M     2047M   2047M
08:40:01   193274M   4787M      3M 66935M    0M 114134M     2047M   2047M
08:50:01   193274M   4367M      3M 66948M    0M 114136M     2047M   2047M
09:00:01   193274M   3919M      3M 66955M    0M 114139M     2047M   2047M
09:10:01   193274M   3221M      3M 67350M    0M 114154M     2047M   2047M
09:20:01   193274M   3239M      3M 67355M    0M 114153M     2047M   2047M
09:30:01   193274M   3178M      3M 67359M    0M 114155M     2047M   2047M
09:40:01   193274M   2417M      3M 67363M    0M 114554M     2047M   2047M
09:50:01   193274M   2367M      3M 67357M    0M 114554M     2047M   2047M
10:00:01   193274M   1819M      3M 67820M    0M 114574M     2047M   2047M
10:10:01   193274M   1900M      3M 67867M    0M 114571M     2047M   2047M
10:20:01   193274M   1467M      3M 67876M    0M 114573M     2047M   2047M
10:30:01   193274M    955M      2M 68258M    0M 114579M     2047M   2047M
10:40:01   193274M   1251M      2M 68263M    0M 114580M     2047M   2047M

Большое спасибо заранее!

 , , , ,

Igorek ()

Shared memory на практике

Необходимо для нескольких программ с похожим функционалом сделать некоторую общую память до 10МБ аля кеш, в котором 2-ая программа может использовать захешированные данные 1-ой программой, добавлять свои данные в кеш и чтоб 1-ая программа также могла их использовать. Если некоторые закешированные данные не используются ни одной программой - они удаляются. Общий функционал вынесен в библиотеку, а теперь вопросы:
1. может ли библиотека сама рулить общей памятью?
2. или нужен процесс-посредник?
3. а может позволить программам самим взаимодействовать с общей памятью? Что с экранированием?

 , , , ,

zusazo ()

Проверка наличия такого блока в shmget

Мне нужно, чтобы первый, кому понадобится блок его проинициализировал, остальным нужен доступ «только на чтение». Я так понимаю, что действовать надо как-то так:

if ((id = shmget(..., ..., 0444 | IPC_CREATE | IPC_EXCL)) == -1)
{
   id = shmget(..., ..., 0666 | PC_CREATE);
   initdata(id) // shmat внутри
}

char * data = (char *)shmat(id, 0, 0);

Но так получается, что тот, кто инициализировал имеет доступ и на запись. Имеет смысл после инициализации переоткрыть id по 0444 или уже навсегда этому блоку будут выданы права 0666? Будет ли идеологически верным переоткрывать по 0444?

Дополнительный опциональный вопрос по ftok - оно должно брать имя существующего файла. `touch /tmp/somename' подойдет?

P.S. Бггг, у нас нет тега unix system v.

 

sambist ()

Константный массив, расшаренный для библиотеки.

liba.so
b.exe
c.exe

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

 

sambist ()