ПРОБЛЕМЫ, КОТОРЫЕ МЫ МОЖЕМ РЕШИТЬ:
Платить меньше в два-три раза
Вы можете платить меньше лицензий "за ядро" (до 2-3 раз).
Больше виртуальных машин
В сценариях консолидации вы можете запустить на 50% больше виртуальных машин.
Моментальная оптимизация
Выполните моментальную оптимизацию производительности, не затрагивая код приложений.
Повышение надежности
Повышается надёжность и стабильность сервисов. Экономия на электропитании .
Уменьшение требований к ресурсам
Может снижать: потребление оперативной памяти и её фрагментацию, нагрузку на ЦПУ, энергопотребление оборудования.
Работаем дольше
Вы можете использовать существующее оборудование много
дольше (снижается TCO ).
дольше (снижается TCO ).
LIGHTWEIGHT MEMORY ALLOCATOR
О НАС:
●КОМАНДА ПРОФЕССИОНАЛОВ
Мы команда профессионалов, с большим опытом в IT (базы данных, управление проектами, техническое сопровождение, программирование, техническая поддержка) более 20 лет у каждого. Сам проект создавался свыше 10 лет, основываясь на опыте в эксплуатации систем, глубоком исследовании существующих решений, глубоком знании особенностей и стандартов программного обеспечения и операционных систем. Мы уверены в своём продукте, его качестве и явном лидерстве среди конкурентов.
●ТЕХНИЧЕСКАЯ ПОДДЕРЖКА 24/7
Мы обеспечиваем техническую поддержку 24/7 с временем реакции 15 минут. Мы уверены в качестве своего продукта и готовы вместе с Вами заниматься его оптимизацией (при необходимости) под Ваши нужды.
●УНИКАЛЬНОЕ РЕШЕНИЕ
Наш продукт отличается от конкурентов кардинально. Скорость, масштабируемость, количество поддерживаемых платформ, легкость в установке (и в выключении) — у нас просто нет конкурентов сравнимого уровня.
●КОМАНДА ПРОФЕССИОНАЛОВ
Мы команда профессионалов, с большим опытом в IT (базы данных, управление проектами, техническое сопровождение, программирование, техническая поддержка) более 20 лет у каждого. Сам проект создавался свыше 10 лет, основываясь на опыте в эксплуатации систем, глубоком исследовании существующих решений, глубоком знании особенностей и стандартов программного обеспечения и операционных систем. Мы уверены в своём продукте, его качестве и явном лидерстве среди конкурентов.
●ТЕХНИЧЕСКАЯ ПОДДЕРЖКА 24/7
Мы обеспечиваем техническую поддержку 24/7 с временем реакции 15 минут. Мы уверены в качестве своего продукта и готовы вместе с Вами заниматься его оптимизацией (при необходимости) под Ваши нужды.
●УНИКАЛЬНОЕ РЕШЕНИЕ
Наш продукт отличается от конкурентов кардинально. Скорость, масштабируемость, количество поддерживаемых платформ, легкость в установке (и в выключении) — у нас просто нет конкурентов сравнимого уровня.
ПОЧЕМУ LMA?
- LMA - самый быстрый на планете тредовый аллокатор
- Все malloc/free/realloc имеют сложность O(1)
- Чем выше частота процессора, тем быстрее мы работаем!
- Подходит для любых приложений, интенсивно работающих с памятью
- Уменьшает утилизацию CPU, снижая требования по электропитанию
- Уменьшает латентность и повышает общую производительность систем
- Подходит для большинства CPU/OС
КОМУ МЫ ПОЛЕЗНЫ?
●Компаниям, желающим ускорить свои приложения и сервисы.
●Компаниям, испытывающим проблемы с производительностью информационных систем, в том числе критических для бизнеса.
●Очевидными кандидатами на применение аллокатора являются: веб-серверы, большинство прокси-серверов, DNS-серверы, реляционные базы данных (наиболее типичные конфигурации), системы кэширования, AV-сканеры, системы регистрации/мониторинга (исключая скриптинг), сервера приложений, написанные на C/C++, многие non-SQL и in-memory базы данных, целый ряд вычислительных задач с интенсивным использованием памяти и т. д.
●Компаниям, желающим ускорить свои приложения и сервисы.
●Компаниям, испытывающим проблемы с производительностью информационных систем, в том числе критических для бизнеса.
●Очевидными кандидатами на применение аллокатора являются: веб-серверы, большинство прокси-серверов, DNS-серверы, реляционные базы данных (наиболее типичные конфигурации), системы кэширования, AV-сканеры, системы регистрации/мониторинга (исключая скриптинг), сервера приложений, написанные на C/C++, многие non-SQL и in-memory базы данных, целый ряд вычислительных задач с интенсивным использованием памяти и т. д.
ВОЗМОЖНОСТИ LMA:
Экстремально низкая фрагментация памяти (внешняя и внутренняя), что снижает частоту вызывов OOM Killer или крах нод- Тредовая архитектура с минималистическими внутренними блокировками (нет мьютексов) с высоким масштабированием (128+ процессорных ядер)
- Выделяемая аллокатором память всегда выровнена
- Никогда не выполняет оверкоммитов
- Высочайшая производительность аллокаций (алгоритмическая сложность O(1))
- Работает на голом железе или в любых виртуальных средах
- Встроенный автоматический сборщик мусора (GC), управляемый переменной среды
- Возможна кастомизация или настройка под специфические требования
- Включены рантаймы, минимизирующие внешние зависимости
- Поддержка 32/64 bit (для большинства ОС)
- Поддержка Linux/Solaris/*BSD/AIX
- Поддержка процессоров x86/x86_64/SPARC/POWER/ARM
ЗАКАЗАТЬ ДЕМО-ВЕРСИЮ
Оставьте, пожалуйста, свои контактные данные - мы с Вами обязательно свяжемся.
e-mail: sales@thecacheworks.com
ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ:
Тест на многопоточность в сравнении с конкурентами.
Аллокатор работает «в двух измерениях» - одновременно снижая нагрузку на ЦПУ и ускоряя при этом запросы приложений на выделение памяти в операционной системе. Благодаря этому можно:
- Установить менее мощное (а значит более дешёвое оборудование) для вашего приложения, сохраняя прежнюю скорость работы;
- Сократить затраты на электроэнергию (падает нагрузка на ЦПУ — это отражается на потребляемом оборудовании электричестве);
- Можно реже менять оборудование — снижаются требования к ресурсам (память и/или CPU);
- Можно снизить требуемое количество лицензий для приложений, лицензируемых по количеству процессоров;
- Для некоторых приложений уменьшается время отклика (latency);
- Для некоторых приложений увеличивается скорость работы.
- Установить менее мощное (а значит более дешёвое оборудование) для вашего приложения, сохраняя прежнюю скорость работы;
- Сократить затраты на электроэнергию (падает нагрузка на ЦПУ — это отражается на потребляемом оборудовании электричестве);
- Можно реже менять оборудование — снижаются требования к ресурсам (память и/или CPU);
- Можно снизить требуемое количество лицензий для приложений, лицензируемых по количеству процессоров;
- Для некоторых приложений уменьшается время отклика (latency);
- Для некоторых приложений увеличивается скорость работы.
Мы не тестировали и не профилировали все на свете программное обеспечение. Многое – но совсем не все.
Правильный ответ — надо тестировать. Причем тестировать нужно непосредственно вам и ваши конкретные приложения под реальной нагрузкой - в наших тестах мы вам какой угодно результат покажем. Разного рода синтетические бенчмарки в подавляющем большинстве случаев нерепрезентативны. Измерения одиночных запросов или операций также нерепрезентативны. В идеале, вам стоит протрассировать или отпрофилировать приложение-кандидат (если вы плохо представляете себе его профиль использования памяти), и примерно прикинуть. Если у вас трассировка показывает, скажем, 10000 аллокаций в час - особого эффекта не ждите. 5-10% максимум. Но если вы видите, например, 200к аллокаций в секунду - совсем другое дело, и есть смысл прикладывать дальнейшие усилия.
Очевидными кандидатами на применение аллокатора являются: веб-серверы, большинство прокси- серверов, DNS-серверы, реляционные базы данных (наиболее типичные конфигурации), системы кэширования, AV-сканеры, системы регистрации/мониторинга (исключая скриптинг), сервера приложений, написанные на C/C++ (особенно с использованием STL), многие non-SQL и in-memory базы данных, целый ряд вычислительных задач с интенсивным использованием памяти и т. п.
Правильный ответ — надо тестировать. Причем тестировать нужно непосредственно вам и ваши конкретные приложения под реальной нагрузкой - в наших тестах мы вам какой угодно результат покажем. Разного рода синтетические бенчмарки в подавляющем большинстве случаев нерепрезентативны. Измерения одиночных запросов или операций также нерепрезентативны. В идеале, вам стоит протрассировать или отпрофилировать приложение-кандидат (если вы плохо представляете себе его профиль использования памяти), и примерно прикинуть. Если у вас трассировка показывает, скажем, 10000 аллокаций в час - особого эффекта не ждите. 5-10% максимум. Но если вы видите, например, 200к аллокаций в секунду - совсем другое дело, и есть смысл прикладывать дальнейшие усилия.
Очевидными кандидатами на применение аллокатора являются: веб-серверы, большинство прокси- серверов, DNS-серверы, реляционные базы данных (наиболее типичные конфигурации), системы кэширования, AV-сканеры, системы регистрации/мониторинга (исключая скриптинг), сервера приложений, написанные на C/C++ (особенно с использованием STL), многие non-SQL и in-memory базы данных, целый ряд вычислительных задач с интенсивным использованием памяти и т. п.
Очевидно, что приложения с длительными, интенсивными или тяжеловесными IO-операциями почти никогда не ускоряются. Львиную долю времени в отчетности занимает собственно ввод-вывод, а аллокаций в большинстве случаев исчезающе мало (исключения бывают; необходимо профилировать приложение).
По нашему опыту, отчетность (DSS) – не самый лучший кандидат на ускорение аллокациями. Гораздо эффективнее в подобных ситуациях потратиться на оптимизацию запросов и устранение узких мест во вводе-вывода. Однако, ввиду существования исключений, стоит провести профилирование и тесты – если для вас настолько критична отчетность. Нам известны случаи, когда применение нашего решения к отчетности как минимум вдвое снижало утилизацию CPU в ходе выполнения запросов.
Что касается резервов, имеющихся у OLTP – заметим, что при 70% утилизации CPU резервы имеют склонность мгновенно исчерпываться при легкой перегрузке и утилизация превращается в 400%. Собственно, при уровне утилизации 70% принято начинать оптимизацию или работы по масштабированию.
По нашему опыту, отчетность (DSS) – не самый лучший кандидат на ускорение аллокациями. Гораздо эффективнее в подобных ситуациях потратиться на оптимизацию запросов и устранение узких мест во вводе-вывода. Однако, ввиду существования исключений, стоит провести профилирование и тесты – если для вас настолько критична отчетность. Нам известны случаи, когда применение нашего решения к отчетности как минимум вдвое снижало утилизацию CPU в ходе выполнения запросов.
Что касается резервов, имеющихся у OLTP – заметим, что при 70% утилизации CPU резервы имеют склонность мгновенно исчерпываться при легкой перегрузке и утилизация превращается в 400%. Собственно, при уровне утилизации 70% принято начинать оптимизацию или работы по масштабированию.
Вообще говоря, и не должен. Подобные операции на 95% состоят из массированного ввода-вывода, используют сравнительно мало аллокаций и имеют узкое место в пропускной способности подсистемы ввода-вывода. Кроме того, миграции часто представляют собой очень комплексные операции, к которым небезопасно прикладывать аллокатор глобально – вы же не будете тестировать каждый отдельный шаг на совместимость. В подобных ситуациях правильное действие – нанять квалифицированных админов, умеющих выполнять оптимизации обычным, не волшебным, образом.
Зависит от многих факторов. Как и в других случаях, необходимо профилирование и реальное тестирование. При этом не исключается необходимость предварительной диагностики, устранения узких мест и/или оптимизации производительности, как и сказано в документации.
Волшебной пули, способной одним махом решить вообще все и любые проблемы с производительностью, мы не обещали. Аллокатор делает то, что он должен делать – ускоряет аллокации памяти. Он не может заменить ни системного администратора, ни необходимость проведения диагностики и устранения хотя бы наиболее узких мест, ни выполнение хотя бы плохонького предварительного тюнинга.
Сначала устраните узкие места – потом выполните профилирование, и лишь затем, в зависимости от его результатов, используйте аллокатор.
Сначала устраните узкие места – потом выполните профилирование, и лишь затем, в зависимости от его результатов, используйте аллокатор.
Соседний заказчик для вас совершенно нерепрезентативен – у него другие задачи, другие требования, другая операционная среда. Если вы рассчитываете подобным образом сэкономить время и уменьшить свои (и без того исчезающе малые) риски – вы просто зря теряете время. Вам в любом случае понадобится проводить собственные тесты и принимать собственные решения.
Мы не можем этого знать. Мы ваших систем не видели, не исследовали и не профилировали. Это можете знать только вы. Вы же умеете читать, изучили документацию, подумали, оценили, исследовали приложения, провели их профилирование, провели тесты или собираетесь их провести; а до этого вы уже неоднократно проводили диагностику узких мест. В ходе этих работ вы и определяете целевой KPI. Причем, вы же понимаете, что KPI во всех случаях будет разный. Ведь понимаете, да?
Прежде всего, внимательно прочитать руководство по тестированию. Затем вспомнить программистскую народную мудрость – "Каждая оптимизация производительности программы должна начинаться с измерения". Затем вернуться к руководству по тестированию – и перечитать его еще раз. Затем начать действовать по описанному в руководстве плану.
На тему бенчмарков уже отвечали выше. Также ответ продублирован в документации. И – да, мы не говорили, что даем вам волшебную пулю, ускоряющую все на свете. И – нет, совсем ничего не делая, волшебных результатов получить не удастся. Даже с нашей программой. Придется приложить определенные усилия – как умственные, так и физические. Возможно даже, что сперва потребуется вполне себе реальный performance tuning. Просто же перебирать синтетические бенчмарки, чтобы нас уязвить – контрпродуктивно. Мы и сами знаем, где ничем не можем помочь. Исходя из нашего опыта — множество бенчмарков начинают тестировать совсем не то (например заявлены тесты аллокации памяти, а в реальности генерируется тяжёлый IO для нагрузки ядер процессора на 100 процентов).
Никакой. Синтетические бенчмарки не показывают реальной картины. Тестируйте на собственных реальных приложениях и с реальной нагрузкой. У себя внутри мы используем с реальными приложениями, получаем десятикратное увеличение RPS – вы же нам не поверите? И правильно сделаете. Скажете, что мы фокусники и что угодно нарисуем или в лабраторных условиях получим абсолютно любой результат.
Что касается Оракла – увы, для него не существует официального бесплатного бенчмарка, который бы являлся хотя бы в какой-то степени удовлетворительным. Все, что есть в наличии – либо требует доработки напильником, либо нерепрезентативно, либо требует больших трудозатрат, либо стоит денег. Конечно, всегда остается TPC. Но бесплатно он не проводится, как вы понимаете.
Что касается Оракла – увы, для него не существует официального бесплатного бенчмарка, который бы являлся хотя бы в какой-то степени удовлетворительным. Все, что есть в наличии – либо требует доработки напильником, либо нерепрезентативно, либо требует больших трудозатрат, либо стоит денег. Конечно, всегда остается TPC. Но бесплатно он не проводится, как вы понимаете.
Если у вас Oracle, прежде всего убедитесь, что у вас достаточного размера swap. Да, даже если у вас 1 Тб оперативной памяти. Да, вы не ослышались. Да, не менее одного объема физической памяти. Убедитесь, что у вас в принципе достаточно физической памяти. Проверьте параметры аллокатора, если вы их меняли – помните, больше не всегда означает лучше.
Вообще, swap жизненно необходим во всех ситуациях и с любым ПО. Падать по нехватке памяти мы считаем очень плохой идеей.
Вообще, swap жизненно необходим во всех ситуациях и с любым ПО. Падать по нехватке памяти мы считаем очень плохой идеей.
Первая линия техподдержки работает 24*7 (для клиентов, купивших техподдержку). Мы Вас понимаем и всегда поддержим в режиме 24*7. В свою очередь, вы можете помочь нашей поддержке, тщательно описывая детали и обстоятельства (не так, как обычно – "Я что-то нажала и оно сломалось!"), а также помня о том, что нашим телепатам из третьей линии поддержки крайне необходимо видеть стектрейс, чтобы сказать вам в точности, что же сломалось и где. Больше относящихся к делу подробностей – это о поддержке.
Так как продуктивные системы клиента являются весьма критичными, для оказания качественной поддержки нам необходимо воспроизвести баг у себя. С тем, чтобы затем со "скальпелями в руках" наброситься на нашу систему, на которой мы его воспроизвели. Поэтому, чем больше информации вы сообщите поддержке – тем быстрее и легче будет исправить баг или проблему. Две вещи: стектрейс и информация, необходимая для воспроизведения бага. Помните об этом.
Так как продуктивные системы клиента являются весьма критичными, для оказания качественной поддержки нам необходимо воспроизвести баг у себя. С тем, чтобы затем со "скальпелями в руках" наброситься на нашу систему, на которой мы его воспроизвели. Поэтому, чем больше информации вы сообщите поддержке – тем быстрее и легче будет исправить баг или проблему. Две вещи: стектрейс и информация, необходимая для воспроизведения бага. Помните об этом.
Стектрейс и описание действий, непосредственно предшествующих крэшу – в студию!
Что ж, очень жаль. И нас, и вас, и ваш сервер с вашим же SLA.
Стектрейс – это, как правило, единственная достоверная возможность выяснить, что же, собственно, произошло . Если вы их не анализируете – о, мы понимаем, насколько вам некогда! - остается лишь попытаться телепатически угадать, что случилось и почему. Никто, включая нас, не умеет телепатически читать ваши логи или, тем более, дизассемблировать в уме. Иногда без стектрейсов возможно обойтись. В хорошо известных случаях, или с хорошо нам известным программным обеспечением. Однако, как правило – нет. Если вас беспокоит, что дампы (или "корки") забивают диски сервера – то включите их хотя бы временно, до воспроизведения проблемы и снятия стектрейса. В противном случае – понять причину ошибки будет просто невозможно.
Стектрейс – это, как правило, единственная достоверная возможность выяснить, что же, собственно, произошло . Если вы их не анализируете – о, мы понимаем, насколько вам некогда! - остается лишь попытаться телепатически угадать, что случилось и почему. Никто, включая нас, не умеет телепатически читать ваши логи или, тем более, дизассемблировать в уме. Иногда без стектрейсов возможно обойтись. В хорошо известных случаях, или с хорошо нам известным программным обеспечением. Однако, как правило – нет. Если вас беспокоит, что дампы (или "корки") забивают диски сервера – то включите их хотя бы временно, до воспроизведения проблемы и снятия стектрейса. В противном случае – понять причину ошибки будет просто невозможно.
Мы стараемся изо всех сил, чтобы это было так. Мы не работаем по айджайлу или скраму. Мы понимаем, на каком уровне используют наше решение и насколько критично качество. У нас жесткие внутренние критерии. Дивизион разработки и тестирования проводит на постоянной основе тщательные аудиты кода и полный спектр тестов. Мы стараемся протестировать каждое изменение на возможно большем числе программ, сервисов и платформ. Что касается стектрейсов – да, мы уверены в своем коде. Однако наш опыт показывает, что и проблемы совместимости бывают, да и чужой код далеко не всегда бывает совершенным (особенно в семействе Linux). И стектрейсы помогают нам разобраться в проблеме с тем, чтобы ее решить.
Да, мы его используем. Так широко, как это только возможно. У нас он много лет используется в продуктивных средах (БД, Networking, Cache). Поэтому, как правило, мы не дожидаемся багрепортов, а находим и исправляем баги значительно раньше, чем нам о них сообщают.
Цена зависит от нескольких параметров: типа процессоров (мы поддерживаем x86, SPARC, POWER, ARM), физического количества процессоров/ядер, операционной системы (Linux, Solaris, AIX, и т/д). Ввиду большого разнообразия — лучше обратиться в отдел продаж по адресу: sales@thecacheworks.com
Ввиду широкого круга поддерживаемых платформ ( x86, SPARC, POWER, ARM) и операционных систем (Linux, Solaris, AIX, и т/д) — часто приходится собирать демо именно под Вашу систему. Особенно это касается большого «зоопарка» версий и дистрибутивов семейства Linux.
В подавляющем большинстве случаев либо сразу при запуске происходит крэш (что обычно означает, что программа или сервис с нашим продуктом несовместимы – в руководстве описано, в каких случаях или с какими программными продуктами мы можем оказаться несовместимы), либо вы в первые же 2-7 дней увидите эффект. По нашему опыту, практически не существует бизнесов с основным технологическим циклом длинее 30 суток. Помимо того, что мы ценим ваше время. Поэтому мы считаем, что трайла в 30 дней более, чем достаточно, чтобы провести тестирование и оценить результат.
Напишите нам через форму обратной связи. Мы с Вами обязательно свяжемся или пришлите запрос на e-mail: sales@thecacheworks.com